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

[Pharo-project] is pharo ready for production?

by Esteban Lorenzano

Hi, I'm planning to start a new commercial, seaside based project in a few weeks, and I wish to start it in Pharo, but I'm afraid is not very stable yet... Can somebody tell me if is usable right now and if not, more or less when it will be? Thanks, Esteban

Sept. 16, 2008

Re: [Pharo-project] [ANN] update 10072

by StÃ©phane Ducasse

welcome to Shitty Interface (TM) world! >> btw, Marcus, why you posted it under squeak+freetype category? >> > > I did it yesterday, and the file never showed up... so that's were > it ended up! > (I deleted this wrong file now, the 10072 is now part of pharo) > > marcus

Sept. 16, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

2008/9/16 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > > On Sep 14, 2008, at 12:39 PM, Igor Stasenko wrote: > >> My wish behind all of this is to provide clean separation between core >> VM and UI. Then, in Hydra each image could create and manage own >> windows. > > To complicate things on os-x (macintosh, iPhone) any UI related calls can > only be done on the main thread. > Thus you cannot open a window, draw, or check the window size, etc on thread > 27.... > > Solving this problem on os-x with the current macintosh VMs requires the VM > to be clever. > > This clever coding does not work on the iPhone, although this is an open bug > with Apple. > > For the iPhone we build a "graphic atom" for each display request. On the > flush to screen call, we then bundle up the queued atoms and create > a "frame update request" which is then executed as a frame region invalidate > request on the main thread via a cross thread API call. > This triggers (later) an update event on the main thread for the invalidated > frame or frames, where we remove the frame update request or requests from > the queue, > and paint the queued frame updates > Well, i don't see much problem with it. For instance, to get more uniform model, i wanted to rewrite UI events mechanism with events which i use in Hydra for passing any UI related events to interpreter. In this case, you could have an OS-dependent event sink in main thread, and then dispatch events to be handled in another thread(s). I think that event model, which i introduced in Hydra could do this quite efficiently and with no much complexity overhead. Same could be done in reverse order - when you need to invoke some function only from main thread - you could simply enqueue an event into main thread with proper function, and eventually it will be handled, calling your code and using your params.. > Another issue which perhaps is not obvious is that FFI calls then might need > to run on the main thread, some are not clear, for example > executing many QuickTime calls (seemly non UI related) on a secondary thread > causes a core dump. > Well, this kind of problem, fairly, is not related to VM - you can't guarantee thread safety from VM side if you allowing foreign calls. Some calls could work, some could crash a system - its completely depends on a functions which you calling. > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 16, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by John M McIntosh

On Sep 14, 2008, at 12:39 PM, Igor Stasenko wrote: > My wish behind all of this is to provide clean separation between core > VM and UI. Then, in Hydra each image could create and manage own > windows. To complicate things on os-x (macintosh, iPhone) any UI related calls can only be done on the main thread. Thus you cannot open a window, draw, or check the window size, etc on thread 27.... Solving this problem on os-x with the current macintosh VMs requires the VM to be clever. This clever coding does not work on the iPhone, although this is an open bug with Apple. For the iPhone we build a "graphic atom" for each display request. On the flush to screen call, we then bundle up the queued atoms and create a "frame update request" which is then executed as a frame region invalidate request on the main thread via a cross thread API call. This triggers (later) an update event on the main thread for the invalidated frame or frames, where we remove the frame update request or requests from the queue, and paint the queued frame updates Another issue which perhaps is not obvious is that FFI calls then might need to run on the main thread, some are not clear, for example executing many QuickTime calls (seemly non UI related) on a secondary thread causes a core dump. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Sept. 16, 2008

Re: [Pharo-project] [ANN] update 10072

by Marcus Denker

On 16.09.2008, at 11:10, Igor Stasenko wrote: > btw, Marcus, why you posted it under squeak+freetype category? > I did it yesterday, and the file never showed up... so that's were it ended up! (I deleted this wrong file now, the 10072 is now part of pharo) marcus > 2008/9/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Ok I thought it was a classOrganizer so nothing serious. >> I tried to find it too but could not. >> >> Stef >> >> On Sep 16, 2008, at 10:11 AM, Marcus Denker wrote: >> >>> >>> On 16.09.2008, at 09:24, StÃ©phane Ducasse wrote: >>> >>>> Marcus >>>> >>>> But changesOrganizer is not important? >>>> >>> >>> a reference was introduced by this fix: >>> >>> http://code.google.com/p/pharo/issues/detail?id=95 >>> >>> I honestly don;t know if there was ever a ChangesOrganizer in >>> Squeak. It's >>> not in 3.9, either. >>> >>> Marcus >>> >>> >>>>> >>>>>> This is strange that ChangesOrganizer got removed. >>>>>> May be we should rollback 10072 >>>>>> >>>>> >>>>> No, that would be too much work to recreate as opposed to see >>>>> what was >>>>> removed. Maybe I just harvested a wrong test... >>>>> >>>>>> BTW alex is working on a test server with laffont and this will >>>>>> help us >>>>>> a lot. >>>>>> >>>>>> Stef >>>>>> >>>>>> On Sep 15, 2008, at 9:59 PM, Adrian Lienhard wrote: >>>>>> >>>>>>> I run the tests in 10072. We currently have 5 failures and a >>>>>>> hand full >>>>>>> of errors. The errors come from the class ChangesOrganizer >>>>>>> being removed but >>>>>>> there are references to it in ChangeHooksTest. >>>>>>> >>>>>>> Two MonthTest tests fail because the following method now >>>>>>> looks like: >>>>>>> Month>>index >>>>>>> | t | >>>>>>> t := 5 >>>>>>> >>>>>>> which obviously was an inadvertent change ;) >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>>> On Sep 15, 2008, at 14:54 , Marcus Denker wrote: >>>>>>> >>>>>>>> >>>>>>>> On 15.09.2008, at 12:42, Damien Cassou wrote: >>>>>>>> >>>>>>>>> Would be cool to create a release now. >>>>>>>>> >>>>>>>> >>>>>>>> yes, I will make a zip today (evening). besides, I want to do a >>>>>>>> one-cklick image based >>>>>>>> on the seaside one later this week. >>>>>>>> >>>>>>>> Marcus >>>>>>>> >>>>>>>> >>>>>>>>> On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker >>>>>>>>> <denker(a)iam.unibe.ch> wrote: >>>>>>>>>> >>>>>>>>>> update10072 >>>>>>>>>> ----------- >>>>>>>>>> >>>>>>>>>> -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej >>>>>>>>>> -> Issue 174: XMLSupport can't be loaded into latest >>>>>>>>>> Pharo image >>>>>>>>>> -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) >>>>>>>>>> -> Issue 106: 7090 DSAunimplementedCleanup >>>>>>>>>> -> Issue 77: 7127 RemoveMappedCollection >>>>>>>>>> -> More ifNil: refactorings >>>>>>>>>> -> replace all occurrances of "isNil not" with "notNil" >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>>>>>>> http://www.iam.unibe.ch/~denker >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Pharo-project mailing list >>>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Damien Cassou >>>>>>>>> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us >>>>>>>>> good >>>>>>>>> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-project mailing list >>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>>> -- >>>>>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>>>>> http://www.iam.unibe.ch/~denker >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> -- >>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>> http://www.iam.unibe.ch/~denker >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> -- >>> Marcus Denker -- denker(a)iam.unibe.ch >>> http://www.iam.unibe.ch/~denker >>> >>> >>> _______________________________________________ >>> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 16, 2008

Re: [Pharo-project] [ANN] update 10072

by Igor Stasenko

btw, Marcus, why you posted it under squeak+freetype category? 2008/9/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Ok I thought it was a classOrganizer so nothing serious. > I tried to find it too but could not. > > Stef > > On Sep 16, 2008, at 10:11 AM, Marcus Denker wrote: > >> >> On 16.09.2008, at 09:24, StÃ©phane Ducasse wrote: >> >>> Marcus >>> >>> But changesOrganizer is not important? >>> >> >> a reference was introduced by this fix: >> >> http://code.google.com/p/pharo/issues/detail?id=95 >> >> I honestly don;t know if there was ever a ChangesOrganizer in Squeak. It's >> not in 3.9, either. >> >> Marcus >> >> >>>> >>>>> This is strange that ChangesOrganizer got removed. >>>>> May be we should rollback 10072 >>>>> >>>> >>>> No, that would be too much work to recreate as opposed to see what was >>>> removed. Maybe I just harvested a wrong test... >>>> >>>>> BTW alex is working on a test server with laffont and this will help us >>>>> a lot. >>>>> >>>>> Stef >>>>> >>>>> On Sep 15, 2008, at 9:59 PM, Adrian Lienhard wrote: >>>>> >>>>>> I run the tests in 10072. We currently have 5 failures and a hand full >>>>>> of errors. The errors come from the class ChangesOrganizer being removed but >>>>>> there are references to it in ChangeHooksTest. >>>>>> >>>>>> Two MonthTest tests fail because the following method now looks like: >>>>>> Month>>index >>>>>> | t | >>>>>> t := 5 >>>>>> >>>>>> which obviously was an inadvertent change ;) >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> On Sep 15, 2008, at 14:54 , Marcus Denker wrote: >>>>>> >>>>>>> >>>>>>> On 15.09.2008, at 12:42, Damien Cassou wrote: >>>>>>> >>>>>>>> Would be cool to create a release now. >>>>>>>> >>>>>>> >>>>>>> yes, I will make a zip today (evening). besides, I want to do a >>>>>>> one-cklick image based >>>>>>> on the seaside one later this week. >>>>>>> >>>>>>> Marcus >>>>>>> >>>>>>> >>>>>>>> On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker >>>>>>>> <denker(a)iam.unibe.ch> wrote: >>>>>>>>> >>>>>>>>> update10072 >>>>>>>>> ----------- >>>>>>>>> >>>>>>>>> -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej >>>>>>>>> -> Issue 174: XMLSupport can't be loaded into latest Pharo image >>>>>>>>> -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) >>>>>>>>> -> Issue 106: 7090 DSAunimplementedCleanup >>>>>>>>> -> Issue 77: 7127 RemoveMappedCollection >>>>>>>>> -> More ifNil: refactorings >>>>>>>>> -> replace all occurrances of "isNil not" with "notNil" >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>>>>>> http://www.iam.unibe.ch/~denker >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-project mailing list >>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Damien Cassou >>>>>>>> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >>>>>>>> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> -- >>>>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>>>> http://www.iam.unibe.ch/~denker >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> -- >>>> Marcus Denker -- denker(a)iam.unibe.ch >>>> http://www.iam.unibe.ch/~denker >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> 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.

Sept. 16, 2008

Re: [Pharo-project] [ANN] update 10072

by Marcus Denker

On 15.09.2008, at 12:42, Damien Cassou wrote: > Would be cool to create a release now. > Done: https://gforge.inria.fr/frs/?group_id=1299 Marcus > On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker > <denker(a)iam.unibe.ch> wrote: >> update10072 >> ----------- >> >> -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej >> -> Issue 174: XMLSupport can't be loaded into latest Pharo image >> -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) >> -> Issue 106: 7090 DSAunimplementedCleanup >> -> Issue 77: 7127 RemoveMappedCollection >> -> More ifNil: refactorings >> -> replace all occurrances of "isNil not" with "notNil" >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 16, 2008

Re: [Pharo-project] [ANN] update 10072

by StÃ©phane Ducasse

Ok I thought it was a classOrganizer so nothing serious. I tried to find it too but could not. Stef On Sep 16, 2008, at 10:11 AM, Marcus Denker wrote: > > On 16.09.2008, at 09:24, StÃ©phane Ducasse wrote: > >> Marcus >> >> But changesOrganizer is not important? >> > > a reference was introduced by this fix: > > http://code.google.com/p/pharo/issues/detail?id=95 > > I honestly don;t know if there was ever a ChangesOrganizer in > Squeak. It's not in 3.9, either. > > Marcus > > >>> >>>> This is strange that ChangesOrganizer got removed. >>>> May be we should rollback 10072 >>>> >>> >>> No, that would be too much work to recreate as opposed to see what >>> was removed. Maybe I just harvested a wrong test... >>> >>>> BTW alex is working on a test server with laffont and this will >>>> help us a lot. >>>> >>>> Stef >>>> >>>> On Sep 15, 2008, at 9:59 PM, Adrian Lienhard wrote: >>>> >>>>> I run the tests in 10072. We currently have 5 failures and a >>>>> hand full of errors. The errors come from the class >>>>> ChangesOrganizer being removed but there are references to it in >>>>> ChangeHooksTest. >>>>> >>>>> Two MonthTest tests fail because the following method now looks >>>>> like: >>>>> Month>>index >>>>> | t | >>>>> t := 5 >>>>> >>>>> which obviously was an inadvertent change ;) >>>>> >>>>> Adrian >>>>> >>>>> >>>>> On Sep 15, 2008, at 14:54 , Marcus Denker wrote: >>>>> >>>>>> >>>>>> On 15.09.2008, at 12:42, Damien Cassou wrote: >>>>>> >>>>>>> Would be cool to create a release now. >>>>>>> >>>>>> >>>>>> yes, I will make a zip today (evening). besides, I want to do a >>>>>> one-cklick image based >>>>>> on the seaside one later this week. >>>>>> >>>>>> Marcus >>>>>> >>>>>> >>>>>>> On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker <denker(a)iam.unibe.ch >>>>>>> > wrote: >>>>>>>> update10072 >>>>>>>> ----------- >>>>>>>> >>>>>>>> -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej >>>>>>>> -> Issue 174: XMLSupport can't be loaded into latest Pharo >>>>>>>> image >>>>>>>> -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) >>>>>>>> -> Issue 106: 7090 DSAunimplementedCleanup >>>>>>>> -> Issue 77: 7127 RemoveMappedCollection >>>>>>>> -> More ifNil: refactorings >>>>>>>> -> replace all occurrances of "isNil not" with "notNil" >>>>>>>> >>>>>>>> -- >>>>>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>>>>> http://www.iam.unibe.ch/~denker >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Damien Cassou >>>>>>> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us >>>>>>> good >>>>>>> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> -- >>>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>>> http://www.iam.unibe.ch/~denker >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> -- >>> Marcus Denker -- denker(a)iam.unibe.ch >>> http://www.iam.unibe.ch/~denker >>> >>> >>> _______________________________________________ >>> 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 > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 16, 2008

Re: [Pharo-project] [ANN] update 10072

by Marcus Denker

On 16.09.2008, at 09:24, StÃ©phane Ducasse wrote: > Marcus > > But changesOrganizer is not important? > a reference was introduced by this fix: http://code.google.com/p/pharo/issues/detail?id=95 I honestly don;t know if there was ever a ChangesOrganizer in Squeak. It's not in 3.9, either. Marcus >> >>> This is strange that ChangesOrganizer got removed. >>> May be we should rollback 10072 >>> >> >> No, that would be too much work to recreate as opposed to see what >> was removed. Maybe I just harvested a wrong test... >> >>> BTW alex is working on a test server with laffont and this will >>> help us a lot. >>> >>> Stef >>> >>> On Sep 15, 2008, at 9:59 PM, Adrian Lienhard wrote: >>> >>>> I run the tests in 10072. We currently have 5 failures and a hand >>>> full of errors. The errors come from the class ChangesOrganizer >>>> being removed but there are references to it in ChangeHooksTest. >>>> >>>> Two MonthTest tests fail because the following method now looks >>>> like: >>>> Month>>index >>>> | t | >>>> t := 5 >>>> >>>> which obviously was an inadvertent change ;) >>>> >>>> Adrian >>>> >>>> >>>> On Sep 15, 2008, at 14:54 , Marcus Denker wrote: >>>> >>>>> >>>>> On 15.09.2008, at 12:42, Damien Cassou wrote: >>>>> >>>>>> Would be cool to create a release now. >>>>>> >>>>> >>>>> yes, I will make a zip today (evening). besides, I want to do a >>>>> one-cklick image based >>>>> on the seaside one later this week. >>>>> >>>>> Marcus >>>>> >>>>> >>>>>> On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker <denker(a)iam.unibe.ch >>>>>> > wrote: >>>>>>> update10072 >>>>>>> ----------- >>>>>>> >>>>>>> -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej >>>>>>> -> Issue 174: XMLSupport can't be loaded into latest Pharo >>>>>>> image >>>>>>> -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) >>>>>>> -> Issue 106: 7090 DSAunimplementedCleanup >>>>>>> -> Issue 77: 7127 RemoveMappedCollection >>>>>>> -> More ifNil: refactorings >>>>>>> -> replace all occurrances of "isNil not" with "notNil" >>>>>>> >>>>>>> -- >>>>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>>>> http://www.iam.unibe.ch/~denker >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Damien Cassou >>>>>> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >>>>>> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> -- >>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>> http://www.iam.unibe.ch/~denker >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 16, 2008

Re: [Pharo-project] [ANN] update 10072

by StÃ©phane Ducasse

Marcus But changesOrganizer is not important? > >> This is strange that ChangesOrganizer got removed. >> May be we should rollback 10072 >> > > No, that would be too much work to recreate as opposed to see what > was removed. Maybe I just harvested a wrong test... > >> BTW alex is working on a test server with laffont and this will >> help us a lot. >> >> Stef >> >> On Sep 15, 2008, at 9:59 PM, Adrian Lienhard wrote: >> >>> I run the tests in 10072. We currently have 5 failures and a hand >>> full of errors. The errors come from the class ChangesOrganizer >>> being removed but there are references to it in ChangeHooksTest. >>> >>> Two MonthTest tests fail because the following method now looks >>> like: >>> Month>>index >>> | t | >>> t := 5 >>> >>> which obviously was an inadvertent change ;) >>> >>> Adrian >>> >>> >>> On Sep 15, 2008, at 14:54 , Marcus Denker wrote: >>> >>>> >>>> On 15.09.2008, at 12:42, Damien Cassou wrote: >>>> >>>>> Would be cool to create a release now. >>>>> >>>> >>>> yes, I will make a zip today (evening). besides, I want to do a >>>> one-cklick image based >>>> on the seaside one later this week. >>>> >>>> Marcus >>>> >>>> >>>>> On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker <denker(a)iam.unibe.ch >>>>> > wrote: >>>>>> update10072 >>>>>> ----------- >>>>>> >>>>>> -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej >>>>>> -> Issue 174: XMLSupport can't be loaded into latest Pharo >>>>>> image >>>>>> -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) >>>>>> -> Issue 106: 7090 DSAunimplementedCleanup >>>>>> -> Issue 77: 7127 RemoveMappedCollection >>>>>> -> More ifNil: refactorings >>>>>> -> replace all occurrances of "isNil not" with "notNil" >>>>>> >>>>>> -- >>>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>>> http://www.iam.unibe.ch/~denker >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Damien Cassou >>>>> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >>>>> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> -- >>>> Marcus Denker -- denker(a)iam.unibe.ch >>>> http://www.iam.unibe.ch/~denker >>>> >>>> >>>> _______________________________________________ >>>> 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 > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 16, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by StÃ©phane Ducasse

I agree. Now we can also late bound core boundary. :) I really believe that we should learn. If tomorrow somebody come up with a really nice integration of the package then it can be really core. Stef On Sep 16, 2008, at 9:02 AM, Adrian Lienhard wrote: > Stef, maybe you misunderstood me. I don't argue against putting it > into core... > But I think it does not make a lot of sense in dev. Only if it is in > core, methods like #match: can use it. > > Adrian > > > On Sep 16, 2008, at 08:54 , StÃ©phane Ducasse wrote: > >> No this is something else. >> Look at all the crap in match: and other. I do not think that regex >> is so large that it is a problem. >> There are so much other totally ***useless** things in the image >> that something useful would be really good. >> What we can do: is give it a try we do not have to be perfect the >> first time. >> Having a vision and path to achieve it should not hamper us to try >> and learn. Look at the use of MC :) >> >> Stef >> >> >>> >>> On Sep 16, 2008, at 07:13 , Damien Cassou wrote: >>> >>>> On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard >>>> <adi(a)netstyle.ch> wrote: >>>>> I agree that we should make it clear what to start with >>>>> (obviously the dev >>>>> distribution). >>>>> The list of packages seems ok to me, except for Regex. >>>> >>>> What is your problem with Regex? >>> >>> I think it should either be in core (as Marcus argues) or in no >>> distro. The reason is that this is not a development tool but will >>> be used as a library. Then if you deploy using the core distro, >>> you have to load it anyway. And if we start to add Regex, why not >>> also adding an XML parser? and package XYZ? So we end up >>> accumulating libraries that blow up the image even if they are >>> used only by few people. I'd like to control myself, which >>> packages to make part of the application. >>> >>> Adrian >>> >>> _______________________________________________ >>> 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 >

Sept. 16, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by Adrian Lienhard

Stef, maybe you misunderstood me. I don't argue against putting it into core... But I think it does not make a lot of sense in dev. Only if it is in core, methods like #match: can use it. Adrian On Sep 16, 2008, at 08:54 , StÃ©phane Ducasse wrote: > No this is something else. > Look at all the crap in match: and other. I do not think that regex > is so large that it is a problem. > There are so much other totally ***useless** things in the image > that something useful would be really good. > What we can do: is give it a try we do not have to be perfect the > first time. > Having a vision and path to achieve it should not hamper us to try > and learn. Look at the use of MC :) > > Stef > > >> >> On Sep 16, 2008, at 07:13 , Damien Cassou wrote: >> >>> On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi(a)netstyle.ch> >>> wrote: >>>> I agree that we should make it clear what to start with >>>> (obviously the dev >>>> distribution). >>>> The list of packages seems ok to me, except for Regex. >>> >>> What is your problem with Regex? >> >> I think it should either be in core (as Marcus argues) or in no >> distro. The reason is that this is not a development tool but will >> be used as a library. Then if you deploy using the core distro, you >> have to load it anyway. And if we start to add Regex, why not also >> adding an XML parser? and package XYZ? So we end up accumulating >> libraries that blow up the image even if they are used only by few >> people. I'd like to control myself, which packages to make part of >> the application. >> >> Adrian >> >> _______________________________________________ >> 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

Sept. 16, 2008

Re: [Pharo-project] [ANN] update 10072

by Marcus Denker

On 16.09.2008, at 08:51, StÃ©phane Ducasse wrote: > This is strange that ChangesOrganizer got removed. > May be we should rollback 10072 > No, that would be too much work to recreate as opposed to see what was removed. Maybe I just harvested a wrong test... > BTW alex is working on a test server with laffont and this will help > us a lot. > > Stef > > On Sep 15, 2008, at 9:59 PM, Adrian Lienhard wrote: > >> I run the tests in 10072. We currently have 5 failures and a hand >> full of errors. The errors come from the class ChangesOrganizer >> being removed but there are references to it in ChangeHooksTest. >> >> Two MonthTest tests fail because the following method now looks like: >> Month>>index >> | t | >> t := 5 >> >> which obviously was an inadvertent change ;) >> >> Adrian >> >> >> On Sep 15, 2008, at 14:54 , Marcus Denker wrote: >> >>> >>> On 15.09.2008, at 12:42, Damien Cassou wrote: >>> >>>> Would be cool to create a release now. >>>> >>> >>> yes, I will make a zip today (evening). besides, I want to do a >>> one-cklick image based >>> on the seaside one later this week. >>> >>> Marcus >>> >>> >>>> On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker <denker(a)iam.unibe.ch >>>> > wrote: >>>>> update10072 >>>>> ----------- >>>>> >>>>> -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej >>>>> -> Issue 174: XMLSupport can't be loaded into latest Pharo image >>>>> -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) >>>>> -> Issue 106: 7090 DSAunimplementedCleanup >>>>> -> Issue 77: 7127 RemoveMappedCollection >>>>> -> More ifNil: refactorings >>>>> -> replace all occurrances of "isNil not" with "notNil" >>>>> >>>>> -- >>>>> Marcus Denker -- denker(a)iam.unibe.ch >>>>> http://www.iam.unibe.ch/~denker >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> >>>> -- >>>> Damien Cassou >>>> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >>>> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> -- >>> Marcus Denker -- denker(a)iam.unibe.ch >>> http://www.iam.unibe.ch/~denker >>> >>> >>> _______________________________________________ >>> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 16, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by StÃ©phane Ducasse

No this is something else. Look at all the crap in match: and other. I do not think that regex is so large that it is a problem. There are so much other totally ***useless** things in the image that something useful would be really good. What we can do: is give it a try we do not have to be perfect the first time. Having a vision and path to achieve it should not hamper us to try and learn. Look at the use of MC :) Stef > > On Sep 16, 2008, at 07:13 , Damien Cassou wrote: > >> On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >>> I agree that we should make it clear what to start with (obviously >>> the dev >>> distribution). >>> The list of packages seems ok to me, except for Regex. >> >> What is your problem with Regex? > > I think it should either be in core (as Marcus argues) or in no > distro. The reason is that this is not a development tool but will > be used as a library. Then if you deploy using the core distro, you > have to load it anyway. And if we start to add Regex, why not also > adding an XML parser? and package XYZ? So we end up accumulating > libraries that blow up the image even if they are used only by few > people. I'd like to control myself, which packages to make part of > the application. > > Adrian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 16, 2008

Re: [Pharo-project] [ANN] update 10072

by StÃ©phane Ducasse

This is strange that ChangesOrganizer got removed. May be we should rollback 10072 BTW alex is working on a test server with laffont and this will help us a lot. Stef On Sep 15, 2008, at 9:59 PM, Adrian Lienhard wrote: > I run the tests in 10072. We currently have 5 failures and a hand > full of errors. The errors come from the class ChangesOrganizer > being removed but there are references to it in ChangeHooksTest. > > Two MonthTest tests fail because the following method now looks like: > Month>>index > | t | > t := 5 > > which obviously was an inadvertent change ;) > > Adrian > > > On Sep 15, 2008, at 14:54 , Marcus Denker wrote: > >> >> On 15.09.2008, at 12:42, Damien Cassou wrote: >> >>> Would be cool to create a release now. >>> >> >> yes, I will make a zip today (evening). besides, I want to do a one- >> cklick image based >> on the seaside one later this week. >> >> Marcus >> >> >>> On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker >>> <denker(a)iam.unibe.ch> wrote: >>>> update10072 >>>> ----------- >>>> >>>> -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej >>>> -> Issue 174: XMLSupport can't be loaded into latest Pharo image >>>> -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) >>>> -> Issue 106: 7090 DSAunimplementedCleanup >>>> -> Issue 77: 7127 RemoveMappedCollection >>>> -> More ifNil: refactorings >>>> -> replace all occurrances of "isNil not" with "notNil" >>>> >>>> -- >>>> Marcus Denker -- denker(a)iam.unibe.ch >>>> http://www.iam.unibe.ch/~denker >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Damien Cassou >>> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >>> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> 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 >

Sept. 16, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by Adrian Lienhard

On Sep 16, 2008, at 07:13 , Damien Cassou wrote: > On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> I agree that we should make it clear what to start with (obviously >> the dev >> distribution). >> The list of packages seems ok to me, except for Regex. > > What is your problem with Regex? I think it should either be in core (as Marcus argues) or in no distro. The reason is that this is not a development tool but will be used as a library. Then if you deploy using the core distro, you have to load it anyway. And if we start to add Regex, why not also adding an XML parser? and package XYZ? So we end up accumulating libraries that blow up the image even if they are used only by few people. I'd like to control myself, which packages to make part of the application. Adrian

Sept. 16, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by Michael Rueger

Damien Cassou wrote: > On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> I agree that we should make it clear what to start with (obviously the dev >> distribution). >> The list of packages seems ok to me, except for Regex. > > What is your problem with Regex? See, that was exactly my point ;-) People prefer different sets of stuff in their image. What Pharo could deliver, would be a small core image, then a couple of approved/tested packages or package combinations that are easy to load into the core. And as a service to new developers we could offer the full blown developer image. One thing that makes Squeak difficult, even for me, is that you never have a place to go to when you want an image and a set of packages that are known to work. Usually you end up having to ask on the mailing list which combination of packages and patches work. Like in the old Linux days before Ubuntu. Btw, Eclipse does the same thing, you have the Eclipse core, add on language packages but also pre-packaged, complete environments. Michael

Sept. 16, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by Damien Cassou

On Mon, Sep 15, 2008 at 9:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > I agree that we should make it clear what to start with (obviously the dev > distribution). > The list of packages seems ok to me, except for Regex. What is your problem with Regex? -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 16, 2008

[Pharo-project] [Enh] Monticello package renaming

by Noury Bouraqadi

Hi, I published a dedicated package for MC package renaming on pharo inbox. I also added to the issue tracker (issue 175). http://code.google.com/p/pharo/issues/detail?id=175 Noury ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

Sept. 15, 2008

Re: [Pharo-project] [ANN] update 10072

by Adrian Lienhard

I run the tests in 10072. We currently have 5 failures and a hand full of errors. The errors come from the class ChangesOrganizer being removed but there are references to it in ChangeHooksTest. Two MonthTest tests fail because the following method now looks like: Month>>index | t | t := 5 which obviously was an inadvertent change ;) Adrian On Sep 15, 2008, at 14:54 , Marcus Denker wrote: > > On 15.09.2008, at 12:42, Damien Cassou wrote: > >> Would be cool to create a release now. >> > > yes, I will make a zip today (evening). besides, I want to do a one- > cklick image based > on the seaside one later this week. > > Marcus > > >> On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker >> <denker(a)iam.unibe.ch> wrote: >>> update10072 >>> ----------- >>> >>> -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej >>> -> Issue 174: XMLSupport can't be loaded into latest Pharo image >>> -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) >>> -> Issue 106: 7090 DSAunimplementedCleanup >>> -> Issue 77: 7127 RemoveMappedCollection >>> -> More ifNil: refactorings >>> -> replace all occurrances of "isNil not" with "notNil" >>> >>> -- >>> Marcus Denker -- denker(a)iam.unibe.ch >>> http://www.iam.unibe.ch/~denker >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Damien Cassou >> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by Adrian Lienhard

here my 2 cents... On Sep 15, 2008, at 17:49 , Marcus Denker wrote: > I think it is *extremely* important to only have one download. I agree that we should make it clear what to start with (obviously the dev distribution). The list of packages seems ok to me, except for Regex. > Having pharo nicely bug-free and with green tests is useless if > every users > of it then uses another image. In addition, I don't want a system > where we > need to explain "which image to use?". But this does not exclude the possibility to have instructions on the web page that explain how to use Pharo in a production setting, right? On this page we would of course point to the download of the core image (among other stuff like GC parameter settings, preferences). Adrian

Sept. 15, 2008

[Pharo-project] Re: Re: Fonts

by Andrew Tween

"StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote in message news:C8F15727-4F27-4293-ACAF-78046E476B76@inria.fr... > You can send large file we just will let them pass. > > stef Ok. Attached is the screenshot > > On Sep 15, 2008, at 7:51 PM, Andrew Tween wrote: > >> Hi Gary, >> >> "Gary Chambers" <gazzaguru2(a)btinternet.com> >> wrote >> in message news:82AB7DFBA0D84C53A1D98B941BA44EF3@GuruVista... >>> Specifically the "Alt-k" (opt for Mac users :-) ) keyboard option for >>> ParagraphEditor... >>> With FreeType and many fonts installed the menu is unmanageable (can't >>> even get to the "more" option)... >> >> If you install the latest version of FreeTypePlus - >> http://www.squeaksource.com/FreeTypePlus/FreeType-tween.435.mcz >> then you will see that I have created a basic font picker dialog >> (screenshot too big to attach without moderator approval). >> >> This uses some of the Polymorph modal dialog code, which I extracted >> into a >> separate package, so that it works even if Polymorph is not installed... >> see - >> http://www.squeaksource.com/FreeTypePlus/PinesoftEnhancementsForFreetype-tw… >> >> I no longer install all the available fonts as TextStyles - so your >> existing >> FontPicker is unlikely to work with the latest FreeTypePlus. I am happy >> to >> work with you to get it working again; we will need to discuss what is >> the >> best way to do this. >> >> Storing TextStyles in the TextConstants dictionary seemed like an >> accident >> waiting to happen. TextConstants contains the carriage return character >> under key #CR , alongside the Atlanta TextStyle under key #Atlanta . >> Exactly what would happen if a user's computer happened to contain a >> font >> called 'CR' or 'Centered' or 'EndOfRun' is anyone's guess :) >> >> However, not putting all the fonts into TextConstants as TextStyles does >> mean that some backwards compatibility has been lost. >> >> Cheers, >> Andy >> >> >> >> >> >>> >>> Perhaps it would be good to extend UIManager with an entry-point for >>> choosing a font, passing off to the Polymorph font selector, in our >>> case. >>> >>> Method in question: ParagraphEditor>>changeStyle. >>> >>> Regards, Gary. >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>

Sept. 15, 2008

Re: [Pharo-project] Re: Fonts

by StÃ©phane Ducasse

You can send large file we just will let them pass. stef On Sep 15, 2008, at 7:51 PM, Andrew Tween wrote: > Hi Gary, > > "Gary Chambers" <gazzaguru2(a)btinternet.com> wrote > in message news:82AB7DFBA0D84C53A1D98B941BA44EF3@GuruVista... >> Specifically the "Alt-k" (opt for Mac users :-) ) keyboard option >> for ParagraphEditor... >> With FreeType and many fonts installed the menu is unmanageable >> (can't even get to the "more" option)... > > If you install the latest version of FreeTypePlus - > http://www.squeaksource.com/FreeTypePlus/FreeType-tween.435.mcz > then you will see that I have created a basic font picker dialog > (screenshot too big to attach without moderator approval). > > This uses some of the Polymorph modal dialog code, which I extracted > into a > separate package, so that it works even if Polymorph is not > installed... > see - > http://www.squeaksource.com/FreeTypePlus/PinesoftEnhancementsForFreetype-tw… > > I no longer install all the available fonts as TextStyles - so your > existing > FontPicker is unlikely to work with the latest FreeTypePlus. I am > happy to > work with you to get it working again; we will need to discuss what > is the > best way to do this. > > Storing TextStyles in the TextConstants dictionary seemed like an > accident > waiting to happen. TextConstants contains the carriage return > character > under key #CR , alongside the Atlanta TextStyle under key #Atlanta . > Exactly what would happen if a user's computer happened to contain a > font > called 'CR' or 'Centered' or 'EndOfRun' is anyone's guess :) > > However, not putting all the fonts into TextConstants as TextStyles > does > mean that some backwards compatibility has been lost. > > Cheers, > Andy > > > > > >> >> Perhaps it would be good to extend UIManager with an entry-point >> for choosing a font, passing off to the Polymorph font selector, in >> our case. >> >> Method in question: ParagraphEditor>>changeStyle. >> >> Regards, Gary. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 15, 2008

[Pharo-project] Re: Fonts

by Andrew Tween

Hi Gary, "Gary Chambers" <gazzaguru2(a)btinternet.com> wrote in message news:82AB7DFBA0D84C53A1D98B941BA44EF3@GuruVista... > Specifically the "Alt-k" (opt for Mac users :-) ) keyboard option for > ParagraphEditor... > With FreeType and many fonts installed the menu is unmanageable (can't > even get to the "more" option)... If you install the latest version of FreeTypePlus - http://www.squeaksource.com/FreeTypePlus/FreeType-tween.435.mcz then you will see that I have created a basic font picker dialog (screenshot too big to attach without moderator approval). This uses some of the Polymorph modal dialog code, which I extracted into a separate package, so that it works even if Polymorph is not installed... see - http://www.squeaksource.com/FreeTypePlus/PinesoftEnhancementsForFreetype-tw… I no longer install all the available fonts as TextStyles - so your existing FontPicker is unlikely to work with the latest FreeTypePlus. I am happy to work with you to get it working again; we will need to discuss what is the best way to do this. Storing TextStyles in the TextConstants dictionary seemed like an accident waiting to happen. TextConstants contains the carriage return character under key #CR , alongside the Atlanta TextStyle under key #Atlanta . Exactly what would happen if a user's computer happened to contain a font called 'CR' or 'Centered' or 'EndOfRun' is anyone's guess :) However, not putting all the fonts into TextConstants as TextStyles does mean that some backwards compatibility has been lost. Cheers, Andy > > Perhaps it would be good to extend UIManager with an entry-point for > choosing a font, passing off to the Polymorph font selector, in our case. > > Method in question: ParagraphEditor>>changeStyle. > > Regards, Gary.

Sept. 15, 2008

Re: [Pharo-project] Fonts

by Gary Chambers

Though that only applies to MVC, (essentiallly) duplicated code exists in TextMorphEditor and TextPropertiesMorph... go figure! Gary. ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: "An open mailing list to discuss any topics related to anopen-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> Sent: Monday, September 15, 2008 5:12 PM Subject: [Pharo-project] Fonts > Specifically the "Alt-k" (opt for Mac users :-) ) keyboard option for > ParagraphEditor... > With FreeType and many fonts installed the menu is unmanageable (can't > even get to the "more" option)... > > Perhaps it would be good to extend UIManager with an entry-point for > choosing a font, passing off to the Polymorph font selector, in our case. > > Method in question: ParagraphEditor>>changeStyle. > > Regards, Gary. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by StÃ©phane Ducasse

>> I think it is *extremely* important to only have one download. > > hmm, yes and no. > Wasn't one of the longer term goals of Pharo to provide a small as > possible core image on which everything else can be bootstrapped? Yes it is! But not at the price to say that pharo is a subset. I think that modularity is one aspect and we should be able to have ***packages*** that coexist and are well designed to coexist. What marcus implies is that well factored code and tested should be modular and the infrastructure should support the modular definition of the system. So changes like better support in terms of notification, no etoy plague, no bookMorph plague should help making the system more manageable. May be at the end we will need a module system. Stef

Sept. 15, 2008

[Pharo-project] Fonts

by Gary Chambers

Specifically the "Alt-k" (opt for Mac users :-) ) keyboard option for ParagraphEditor... With FreeType and many fonts installed the menu is unmanageable (can't even get to the "more" option)... Perhaps it would be good to extend UIManager with an entry-point for choosing a font, passing off to the Polymorph font selector, in our case. Method in question: ParagraphEditor>>changeStyle. Regards, Gary.

Sept. 15, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by StÃ©phane Ducasse

> > These are all good points. One of my biggest concerns is code > compatibility. I used enhanced images and developed web applications. > Often I used a method that came with the enhancements and that > failed when I tried to deploy them in my base image. Then I stopped > using the enhancement images and stuck to the basic ones. Is there a > good way to solve this? Integration: ie looking at the extensions made by the packages and identify the ones that should be moved in the core and not. This is unavoidable. Stef

Sept. 15, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by Michael Rueger

Marcus Denker wrote: > I think it is *extremely* important to only have one download. hmm, yes and no. Wasn't one of the longer term goals of Pharo to provide a small as possible core image on which everything else can be bootstrapped? Michael

Sept. 15, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by Norbert Hartl

On Mon, 2008-09-15 at 17:49 +0200, Marcus Denker wrote: > On 15.09.2008, at 17:36, Michael Rueger wrote: > > > Damien Cassou wrote: > >> Hi, > >> I've just started writing a wiki page which details the packages we > >> plan to install in all Pharo distributions. In the Universe, the > > > > All or developer? > > > > I think it is *extremely* important to only have one download. > > Having pharo nicely bug-free and with green tests is useless if every > users > of it then uses another image. In addition, I don't want a system > where we > need to explain "which image to use?". > > On Pharo-Project, there will be *one* download, and it will be a one- > click image. > > >> meta-package 'Pharo packages' permit easy installation of these > >> packages. The wiki page is at: > >> http://code.google.com/p/pharo/wiki/Packages. > > > > The list is way to long, I don't use any of these packages and I > > wouldn't want to see them in a "base" image. > > It's not that bad... shout, e-completion, refactoring-engine and > OmniBrowser. The Regex will be in Pharo anyway > (it's one of the big mistakes of Smalltalk to not bring a standard > regexp, the result are many hard to understand > methods parsing strings in the base system... and no standard for > developers) > > If you look at younger people, e.g the students, they are used to > Eclipse. Refactoring, code completion and > syntax highlighting are for them not optional. For them this is what > an IDE does, there is no question about that. > > I think not providing that would be the wrong way to go. > > As for size: Most code in Sqeueak are abandoned experiments that > nobody uses, if we clean up, we have a lot of > space to grow for stuff that actually is useful. These are all good points. One of my biggest concerns is code compatibility. I used enhanced images and developed web applications. Often I used a method that came with the enhancements and that failed when I tried to deploy them in my base image. Then I stopped using the enhancement images and stuck to the basic ones. Is there a good way to solve this? Norbert

Sept. 15, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by StÃ©phane Ducasse

>>> I agree. Now I would really to see how we can integrate that. For example - overrides out - and removing duplicated functionality (AST once we get the new compiler). Stef >>> > I think it is *extremely* important to only have one download. > > Having pharo nicely bug-free and with green tests is useless if > every users > of it then uses another image. In addition, I don't want a system > where we > need to explain "which image to use?". > > On Pharo-Project, there will be *one* download, and it will be a one- > click image. > >>> meta-package 'Pharo packages' permit easy installation of these >>> packages. The wiki page is at: >>> http://code.google.com/p/pharo/wiki/Packages. >> >> The list is way to long, I don't use any of these packages and I >> wouldn't want to see them in a "base" image. > > It's not that bad... shout, e-completion, refactoring-engine and > OmniBrowser. The Regex will be in Pharo anyway > (it's one of the big mistakes of Smalltalk to not bring a standard > regexp, the result are many hard to understand > methods parsing strings in the base system... and no standard for > developers) > > If you look at younger people, e.g the students, they are used to > Eclipse. Refactoring, code completion and > syntax highlighting are for them not optional. For them this is what > an IDE does, there is no question about that. > > I think not providing that would be the wrong way to go. > > As for size: Most code in Sqeueak are abandoned experiments that > nobody uses, if we clean up, we have a lot of > space to grow for stuff that actually is useful. > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 15, 2008

Re: [Pharo-project] SqueakSVN

by StÃ©phane Ducasse

Yes we want to use that in pharo. Stef On Sep 15, 2008, at 5:06 PM, Gary Chambers wrote: > Nice to see the DiffMorphs being put to use in the screenshots (at > least) of SqueakSVN. > > http://planet.squeak.org/ > > Gary. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 15, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by Marcus Denker

On 15.09.2008, at 17:36, Michael Rueger wrote: > Damien Cassou wrote: >> Hi, >> I've just started writing a wiki page which details the packages we >> plan to install in all Pharo distributions. In the Universe, the > > All or developer? > I think it is *extremely* important to only have one download. Having pharo nicely bug-free and with green tests is useless if every users of it then uses another image. In addition, I don't want a system where we need to explain "which image to use?". On Pharo-Project, there will be *one* download, and it will be a one- click image. >> meta-package 'Pharo packages' permit easy installation of these >> packages. The wiki page is at: >> http://code.google.com/p/pharo/wiki/Packages. > > The list is way to long, I don't use any of these packages and I > wouldn't want to see them in a "base" image. It's not that bad... shout, e-completion, refactoring-engine and OmniBrowser. The Regex will be in Pharo anyway (it's one of the big mistakes of Smalltalk to not bring a standard regexp, the result are many hard to understand methods parsing strings in the base system... and no standard for developers) If you look at younger people, e.g the students, they are used to Eclipse. Refactoring, code completion and syntax highlighting are for them not optional. For them this is what an IDE does, there is no question about that. I think not providing that would be the wrong way to go. As for size: Most code in Sqeueak are abandoned experiments that nobody uses, if we clean up, we have a lot of space to grow for stuff that actually is useful. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 15, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by Damien Cassou

On Mon, Sep 15, 2008 at 5:36 PM, Michael Rueger <m.rueger(a)acm.org> wrote: > Damien Cassou wrote: >> I've just started writing a wiki page which details the packages we >> plan to install in all Pharo distributions. In the Universe, the > > All or developer? We plan to release 2 versions of Pharo: - a pharo-core, dedicated to Pharo developers - a pharo-dev, dedicated to Pharo users Here, I'm talking about pharo-dev. Contrary to squeak-dev, pharo-dev will be official, this will be the public download by default whereas pharo-core will be hidden in the web pages. >> meta-package 'Pharo packages' permit easy installation of these >> packages. The wiki page is at: >> http://code.google.com/p/pharo/wiki/Packages. > > The list is way to long, I don't use any of these packages and I wouldn't > want to see them in a "base" image. You want neither syntax highlighting, nor code completion, nor refactoring tools? Then, you'd probably better stick with pharo-core :-) -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 15, 2008

Re: [Pharo-project] Thinking about Pharo distribution

by Michael Rueger

Damien Cassou wrote: > Hi, > > I've just started writing a wiki page which details the packages we > plan to install in all Pharo distributions. In the Universe, the All or developer? > meta-package 'Pharo packages' permit easy installation of these > packages. The wiki page is at: > http://code.google.com/p/pharo/wiki/Packages. The list is way to long, I don't use any of these packages and I wouldn't want to see them in a "base" image. Michael

Sept. 15, 2008

[Pharo-project] Thinking about Pharo distribution

by Damien Cassou

Hi, I've just started writing a wiki page which details the packages we plan to install in all Pharo distributions. In the Universe, the meta-package 'Pharo packages' permit easy installation of these packages. The wiki page is at: http://code.google.com/p/pharo/wiki/Packages. Please tell me what you think -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 15, 2008

[Pharo-project] SqueakSVN

by Gary Chambers

Nice to see the DiffMorphs being put to use in the screenshots (at least) of SqueakSVN. http://planet.squeak.org/ Gary.

Sept. 15, 2008

Re: [Pharo-project] Learning how to use Polymorph

by Gary Chambers

Hilaire, try this. Menus are something that hasn't fully been addressed by Polymorph yet so looks a little cumbersome (though less so if the indivdual parts had their own methods, like #fileMenu...). exampleWindowWithToolbars "Open an example window with toolbars." |win fileMenu tools dock text holder| win := StandardWindow new. fileMenu := win newMenu. fileMenu addToggle: 'Open' translated target: nil "would be model" selector: #openFile. fileMenu lastItem font: win theme menuFont; icon: MenuIcons smallOpenIcon; keyText: 'Ctrl+O'. fileMenu addToggle: 'Save' translated target: nil selector: #saveFile getStateSelector: nil enablementSelector: nil. fileMenu lastItem font: win theme menuFont; keyText: 'Ctrl+S'. fileMenu addToggle: 'Print...' translated target: nil selector: #print. fileMenu lastItem font: win theme menuFont; icon: MenuIcons smallPrintIcon; keyText: 'Ctrl+P'. tools := win newToolbar: {win newButtonFor: nil "if we had a model it would go here" getState: nil action: #openFile arguments: nil getEnabled: nil label: (ImageMorph new image: MenuIcons smallOpenIcon) help: 'Open file' translated. win newButtonFor: nil getState: nil action: #saveFile arguments: nil getEnabled: nil label: (ImageMorph new image: MenuIcons smallSaveIcon) help: 'Save file' translated. win newButtonFor: nil getState: nil action: #print arguments: nil getEnabled: nil label: (ImageMorph new image: MenuIcons smallPrintIcon) help: 'Print' translated}. holder := StringHolder new. text := win newTextEditorFor: holder getText: #contents setText: #contents: getEnabled: nil. dock := win newToolDockingBar. dock add: 'File' translated font: win theme menuBarFont icon: MenuIcons smallOpenIcon help: 'File operations' translated subMenu: fileMenu; addMorphBack: tools. win addMorph: dock fullFrame: (LayoutFrame fractions: (0@0 corner: 1@0) offsets: (0@0 corner: 0 @ dock minExtent y)); addMorph: text fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1) offsets: (0@dock minExtent y corner: 0 @ 0)). win themeChanged; openInWorld Having no real model to perform the actions you'll get a walkback if any menu/tool item is chosen. Apologies for the requirement of #themeChanged near the end, must get around to fixing that! Regards, Gary. ----- Original Message ----- From: "Hilaire Fernandes" <hilaire(a)ofset.org> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> Sent: Monday, September 15, 2008 1:32 PM Subject: Re: [Pharo-project] Learning how to use Polymorph > 2008/9/15 Gary Chambers <gazzaguru2(a)btinternet.com>: > >> Of course, if you want a window then you can use a StandardWindow >> (subclass >> of SystemWindow) that includes the TEasilyThemed trait and delegate >> requests >> for widgets to that instead. >> >> Hope that helps... > > Yep, I figure out during the week-end. I am now converting step by > step to Polymorph. > I see that Trait can really make such thinkgs easier. > > One think not obvious to me: how to pack a menu bar, toolbar in > StandardWindow, as you did for your professionnal application. > A canonical exemple will be very usefull > > Hilaire > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2008

Re: [Pharo-project] Re: Re: Re: Building VM Freetype

by Norbert Hartl

On Mon, 2008-09-15 at 16:26 +0300, Igor Stasenko wrote: > 2008/9/15 Norbert Hartl <norbert(a)hartl.name>: > > On Mon, 2008-09-15 at 14:44 +0300, Igor Stasenko wrote: > >> 2008/9/15 Norbert Hartl <norbert(a)hartl.name>: > >> > On Mon, 2008-09-15 at 09:53 +0300, Igor Stasenko wrote: > >> >> 2008/9/15 Norbert Hartl <norbert(a)hartl.name>: > >> >> > On Mon, 2008-09-15 at 03:36 +0300, Igor Stasenko wrote: > >> >> >> I managed to build squeak + freetype plugin on my ubuntu box. > >> >> >> Not sure, however how to package resulting binary. > >> >> >> > >> >> > I took a look at the svn repo and there is indeed no other > >> >> > option than installing the binary in the system. I wonder how > >> >> > the vm is usually packed. The links on squeakvm.org for the redhat > >> >> > and debian packages are disabled, too. > >> >> > > >> >> > I can help building debian packages. Maybe it would be good the check > >> >> > in the debian files into svn for easy package creation. > >> >> > > >> >> yes, > >> >> something like > >> >> 'make bin-package' > >> >> would be cool > >> >> > >> >> Btw, Ubuntu having a squeak in its binary packages collection, so i > >> >> think its better to contact with people who actually did it instead of > >> >> repeating doing same. But i can't remember who actually made it. > >> >> > >> > Ah btw. do you know apt-src??? Try to do > >> > > >> > apt-src install squeak-vm > >> > > >> well, it deals with source packages, not binary. People who care to > >> build squeak from sources should really get it from squeakvm.org > >> not from other sources. IMO. > >> > > I'm sure the sources are taken from squeakvm.org. It's just that a > > system like debian has source snapshots. So to build a certain > > version of a package you export those sources into the debian skeleton > > and build the binary from there. This way maintainer and others are > > able to build the same package from the same sources. If sources are > > updated you need to create a new version. It just differs in the way > > you do it. Using a tag from svn to get sources is not the way debian > > handles it. > > Yeah, but how would you deal with sources generated by VMMaker? > We having two sources participating in final result: > - VMMaker > - platforms source. > > unlike from C world, where everything in single package. > > Should such distribution include a VMMaker sources, and then , in some > way build everything from scratch (which requires to having some > version of squeak installed already)? > Otherwise you need to carry the snapshot of generated sources in this > package, which i really don't like. > I don't think there are much alternatives. Somehow you have to freeze the state of the sources. No need to recreate a fixed state with a tool like VMMaker. After VMMaker has finished it is just a bunch of C files. Creating a copy/snapshot of it isn't that bad even if includes svn and vmmaker sources. The rationale behind the deb-src is that there is e.g. a security team in debian that can patch the whole thing if they find a security problem in the sources. That means a debian package is the binary compiled from sources (snapshot) plus patches from the one maintaining the package plus patches from the debian team plus patches from the security team... :) The average user isn't using deb-src. The open source just enables you to do so if you have the need to. Including a plugin in the vm is good use case for that. You take the deb-src and adjust it to your need. If you find the sources being outdated you can email the maintainer. If you want to include stuff do the same. If it is all to tedious or slow you might try _being_ the maintainer ;) Norbert > That's why i'm thinking that best would to distribute binary, not > sources. And people who like to build everything from scratch should > be pointed to squeakvm.org (or any other site, where such binary came > from). > > We're getting back to discussion on squeak-dev, that debian people > don't want to include squeak in their main repository (or how do they > call it). Because squeak don't have a process which can recreate image > purely from source files, and because it is complete stupidity :) > > > > > Please have a look at the debian/changelog file. That is the file where > > the builder takes the version number from. A comment what has changed > > comes along with it. > > > > The easiest way to deal with this is to integrate the debian skeleton in > > the squeakvm repository. Than you can checkout svn and create a package > > from it. And someone needs to update the debian repository so the new > > vm is integrated in the next release. > > > > Norbert > > >

Sept. 15, 2008

Re: [Pharo-project] Re: Re: Re: Building VM Freetype

by Igor Stasenko

2008/9/15 Norbert Hartl <norbert(a)hartl.name>: > On Mon, 2008-09-15 at 14:44 +0300, Igor Stasenko wrote: >> 2008/9/15 Norbert Hartl <norbert(a)hartl.name>: >> > On Mon, 2008-09-15 at 09:53 +0300, Igor Stasenko wrote: >> >> 2008/9/15 Norbert Hartl <norbert(a)hartl.name>: >> >> > On Mon, 2008-09-15 at 03:36 +0300, Igor Stasenko wrote: >> >> >> I managed to build squeak + freetype plugin on my ubuntu box. >> >> >> Not sure, however how to package resulting binary. >> >> >> >> >> > I took a look at the svn repo and there is indeed no other >> >> > option than installing the binary in the system. I wonder how >> >> > the vm is usually packed. The links on squeakvm.org for the redhat >> >> > and debian packages are disabled, too. >> >> > >> >> > I can help building debian packages. Maybe it would be good the check >> >> > in the debian files into svn for easy package creation. >> >> > >> >> yes, >> >> something like >> >> 'make bin-package' >> >> would be cool >> >> >> >> Btw, Ubuntu having a squeak in its binary packages collection, so i >> >> think its better to contact with people who actually did it instead of >> >> repeating doing same. But i can't remember who actually made it. >> >> >> > Ah btw. do you know apt-src??? Try to do >> > >> > apt-src install squeak-vm >> > >> well, it deals with source packages, not binary. People who care to >> build squeak from sources should really get it from squeakvm.org >> not from other sources. IMO. >> > I'm sure the sources are taken from squeakvm.org. It's just that a > system like debian has source snapshots. So to build a certain > version of a package you export those sources into the debian skeleton > and build the binary from there. This way maintainer and others are > able to build the same package from the same sources. If sources are > updated you need to create a new version. It just differs in the way > you do it. Using a tag from svn to get sources is not the way debian > handles it. Yeah, but how would you deal with sources generated by VMMaker? We having two sources participating in final result: - VMMaker - platforms source. unlike from C world, where everything in single package. Should such distribution include a VMMaker sources, and then , in some way build everything from scratch (which requires to having some version of squeak installed already)? Otherwise you need to carry the snapshot of generated sources in this package, which i really don't like. That's why i'm thinking that best would to distribute binary, not sources. And people who like to build everything from scratch should be pointed to squeakvm.org (or any other site, where such binary came from). We're getting back to discussion on squeak-dev, that debian people don't want to include squeak in their main repository (or how do they call it). Because squeak don't have a process which can recreate image purely from source files, and because it is complete stupidity :) > > Please have a look at the debian/changelog file. That is the file where > the builder takes the version number from. A comment what has changed > comes along with it. > > The easiest way to deal with this is to integrate the debian skeleton in > the squeakvm repository. Than you can checkout svn and create a package > from it. And someone needs to update the debian repository so the new > vm is integrated in the next release. > > Norbert > -- Best regards, Igor Stasenko AKA sig.

Sept. 15, 2008

Re: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar

by StÃ©phane Ducasse

Thanks I'm busy too :) but thanks I will have a look at that :) Stef On Sep 15, 2008, at 1:16 PM, Gary Chambers wrote: > Hi Stef. > > Been busy with work-work so haven't had time to review the EToys > removal. There are some methods identified that have not been > verified for removal vs. modification, but I've attached the mcz > here anyway. > > There are a few removals in TheWorldMainDockingBar in the etoys > removals, no mods there. > > The DockingBarMorph is, however, used in Polymorph for toolbars. > There is a potential conflict in Project>>finalEnterActions that is > defined in both Polymorph and EToysRemoval, the EToysRemoval version > should work with Polymorph though (based on Polymorph version with > an additional removal of "world presenter positionStandardPlayer"). > This will cause problems when updating Polymorph though, until I get > some time to split off the overrides into a separate package. > > As for Etoys removal, the package contains changed methods and stubs > (flagged for removal). There are some manual steps required to get > rid of extra cruft (mostly preferences and scripting forms). > > Regards, Gary. > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr > > > To: "An open mailing list to discuss any topics related to an open- > sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, September 12, 2008 4:59 PM > Subject: [Pharo-project] removing the DockingBar and > TheWorldMainDockingBar > > >> Hi all >> >> I was ready to remove the novice mode and I think that we should >> remove DockingBar and TheWorldMainDockingBar >> Now gary it may introduce conflicts with etoy removal. >> What do you think? >> When will you send us the etoy removal? >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > <Pinesoft-Removals-EToys-gvc. > 6.mcz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2008

Re: [Pharo-project] [ANN] update 10072

by Marcus Denker

On 15.09.2008, at 12:42, Damien Cassou wrote: > Would be cool to create a release now. > yes, I will make a zip today (evening). besides, I want to do a one- cklick image based on the seaside one later this week. Marcus > On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker > <denker(a)iam.unibe.ch> wrote: >> update10072 >> ----------- >> >> -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej >> -> Issue 174: XMLSupport can't be loaded into latest Pharo image >> -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) >> -> Issue 106: 7090 DSAunimplementedCleanup >> -> Issue 77: 7127 RemoveMappedCollection >> -> More ifNil: refactorings >> -> replace all occurrances of "isNil not" with "notNil" >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 15, 2008

Re: [Pharo-project] Re: Re: Re: Building VM Freetype

by Norbert Hartl

On Mon, 2008-09-15 at 14:44 +0300, Igor Stasenko wrote: > 2008/9/15 Norbert Hartl <norbert(a)hartl.name>: > > On Mon, 2008-09-15 at 09:53 +0300, Igor Stasenko wrote: > >> 2008/9/15 Norbert Hartl <norbert(a)hartl.name>: > >> > On Mon, 2008-09-15 at 03:36 +0300, Igor Stasenko wrote: > >> >> I managed to build squeak + freetype plugin on my ubuntu box. > >> >> Not sure, however how to package resulting binary. > >> >> > >> > I took a look at the svn repo and there is indeed no other > >> > option than installing the binary in the system. I wonder how > >> > the vm is usually packed. The links on squeakvm.org for the redhat > >> > and debian packages are disabled, too. > >> > > >> > I can help building debian packages. Maybe it would be good the check > >> > in the debian files into svn for easy package creation. > >> > > >> yes, > >> something like > >> 'make bin-package' > >> would be cool > >> > >> Btw, Ubuntu having a squeak in its binary packages collection, so i > >> think its better to contact with people who actually did it instead of > >> repeating doing same. But i can't remember who actually made it. > >> > > Ah btw. do you know apt-src??? Try to do > > > > apt-src install squeak-vm > > > well, it deals with source packages, not binary. People who care to > build squeak from sources should really get it from squeakvm.org > not from other sources. IMO. > I'm sure the sources are taken from squeakvm.org. It's just that a system like debian has source snapshots. So to build a certain version of a package you export those sources into the debian skeleton and build the binary from there. This way maintainer and others are able to build the same package from the same sources. If sources are updated you need to create a new version. It just differs in the way you do it. Using a tag from svn to get sources is not the way debian handles it. Please have a look at the debian/changelog file. That is the file where the builder takes the version number from. A comment what has changed comes along with it. The easiest way to deal with this is to integrate the debian skeleton in the squeakvm repository. Than you can checkout svn and create a package from it. And someone needs to update the debian repository so the new vm is integrated in the next release. Norbert > > In the squeak-vm directory you can invoke > > > > dpkg-buildpackage -nc -uc -rfakeroot > > > > to build the debian package. Sources are under platforms/ directory. > > > > I'll ask Matej were these files are checked in. > > > > Norbert > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > >

Sept. 15, 2008

Re: [Pharo-project] Learning how to use Polymorph

by Hilaire Fernandes

2008/9/15 Gary Chambers <gazzaguru2(a)btinternet.com>: > Of course, if you want a window then you can use a StandardWindow (subclass > of SystemWindow) that includes the TEasilyThemed trait and delegate requests > for widgets to that instead. > > Hope that helps... Yep, I figure out during the week-end. I am now converting step by step to Polymorph. I see that Trait can really make such thinkgs easier. One think not obvious to me: how to pack a menu bar, toolbar in StandardWindow, as you did for your professionnal application. A canonical exemple will be very usefull Hilaire

Sept. 15, 2008

Re: [Pharo-project] Re: Re: Re: Building VM Freetype

by Igor Stasenko

2008/9/15 Norbert Hartl <norbert(a)hartl.name>: > On Mon, 2008-09-15 at 09:53 +0300, Igor Stasenko wrote: >> 2008/9/15 Norbert Hartl <norbert(a)hartl.name>: >> > On Mon, 2008-09-15 at 03:36 +0300, Igor Stasenko wrote: >> >> I managed to build squeak + freetype plugin on my ubuntu box. >> >> Not sure, however how to package resulting binary. >> >> >> > I took a look at the svn repo and there is indeed no other >> > option than installing the binary in the system. I wonder how >> > the vm is usually packed. The links on squeakvm.org for the redhat >> > and debian packages are disabled, too. >> > >> > I can help building debian packages. Maybe it would be good the check >> > in the debian files into svn for easy package creation. >> > >> yes, >> something like >> 'make bin-package' >> would be cool >> >> Btw, Ubuntu having a squeak in its binary packages collection, so i >> think its better to contact with people who actually did it instead of >> repeating doing same. But i can't remember who actually made it. >> > Ah btw. do you know apt-src??? Try to do > > apt-src install squeak-vm > well, it deals with source packages, not binary. People who care to build squeak from sources should really get it from squeakvm.org not from other sources. IMO. > In the squeak-vm directory you can invoke > > dpkg-buildpackage -nc -uc -rfakeroot > > to build the debian package. Sources are under platforms/ directory. > > I'll ask Matej were these files are checked in. > > Norbert > > > _______________________________________________ > 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.

Sept. 15, 2008

Re: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar

by Gary Chambers

I posted a reply to this but it is held "awaiting moderator approval" since the message body is too big. If you like I can repost but put the EToysRemovals on SqueakSource. Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, September 12, 2008 4:59 PM Subject: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar > Hi all > > I was ready to remove the novice mode and I think that we should remove > DockingBar and TheWorldMainDockingBar > Now gary it may introduce conflicts with etoy removal. > What do you think? > When will you send us the etoy removal? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2008

Re: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar

by Gary Chambers

Hi Stef. Been busy with work-work so haven't had time to review the EToys removal. There are some methods identified that have not been verified for removal vs. modification, but I've attached the mcz here anyway. There are a few removals in TheWorldMainDockingBar in the etoys removals, no mods there. The DockingBarMorph is, however, used in Polymorph for toolbars. There is a potential conflict in Project>>finalEnterActions that is defined in both Polymorph and EToysRemoval, the EToysRemoval version should work with Polymorph though (based on Polymorph version with an additional removal of "world presenter positionStandardPlayer"). This will cause problems when updating Polymorph though, until I get some time to split off the overrides into a separate package. As for Etoys removal, the package contains changed methods and stubs (flagged for removal). There are some manual steps required to get rid of extra cruft (mostly preferences and scripting forms). Regards, Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, September 12, 2008 4:59 PM Subject: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar > Hi all > > I was ready to remove the novice mode and I think that we should remove > DockingBar and TheWorldMainDockingBar > Now gary it may introduce conflicts with etoy removal. > What do you think? > When will you send us the etoy removal? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2008

Re: [Pharo-project] Re: Re: Re: Building VM Freetype

by Norbert Hartl

On Mon, 2008-09-15 at 09:53 +0300, Igor Stasenko wrote: > 2008/9/15 Norbert Hartl <norbert(a)hartl.name>: > > On Mon, 2008-09-15 at 03:36 +0300, Igor Stasenko wrote: > >> I managed to build squeak + freetype plugin on my ubuntu box. > >> Not sure, however how to package resulting binary. > >> > > I took a look at the svn repo and there is indeed no other > > option than installing the binary in the system. I wonder how > > the vm is usually packed. The links on squeakvm.org for the redhat > > and debian packages are disabled, too. > > > > I can help building debian packages. Maybe it would be good the check > > in the debian files into svn for easy package creation. > > > yes, > something like > 'make bin-package' > would be cool > > Btw, Ubuntu having a squeak in its binary packages collection, so i > think its better to contact with people who actually did it instead of > repeating doing same. But i can't remember who actually made it. > Ah btw. do you know apt-src??? Try to do apt-src install squeak-vm In the squeak-vm directory you can invoke dpkg-buildpackage -nc -uc -rfakeroot to build the debian package. Sources are under platforms/ directory. I'll ask Matej were these files are checked in. Norbert

Sept. 15, 2008

Re: [Pharo-project] Learning how to use Polymorph

by Gary Chambers

Hi Hilaire, The example builder is specialised so that the example dialogs are not opened modally, just so it is easier to explore using each. There are currently two "standard" ways of utilising Polymorph widgets, depending on whether you are working at the Morph or Model level. For Morph based things: Either include the trait TEasilyThemed that provides access to the api for the morph or subclass ComposableMorph, which does effectively the same thing (assuming it is a "from scratch" morph that does not need to inherit from elsewhere. As an alternative, you may use the "model" way below... For Model based things: Use UITheme newBuilder and request the api from that object (just a ComposableMorph). For example, a method to return a list for a model might look like: newWorkingCopyListMorph "Answer a new list morph for the working copy list." ^UITheme builder newListFor: self list: #workingCopyList selected: #workingCopyListIndex changeSelected: #workingCopyListIndex: help: nil Of course, if you want a window then you can use a StandardWindow (subclass of SystemWindow) that includes the TEasilyThemed trait and delegate requests for widgets to that instead. Hope that helps... Gary. ----- Original Message ----- From: "Hilaire Fernandes" <hilaire(a)ofset.org> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, September 11, 2008 9:09 PM Subject: [Pharo-project] Learning how to use Polymorph > Gary, > > I am looking at Polymorph examples, to start learning it. >>From your example, I see you have this ExampleBuilderMorph class > Is it a class I can use to build my application interface, or do I > need to subclass another MorphicModel (this last class is pretty > large) ? > > I see you are using trait for this class also. > > Hilaire > > > -- > http://blog.ofset.org/hilaire > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 15, 2008

Re: [Pharo-project] [ANN] update 10072

by Damien Cassou

Would be cool to create a release now. On Sun, Sep 14, 2008 at 11:37 PM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > update10072 > ----------- > > -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej > -> Issue 174: XMLSupport can't be loaded into latest Pharo image > -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) > -> Issue 106: 7090 DSAunimplementedCleanup > -> Issue 77: 7127 RemoveMappedCollection > -> More ifNil: refactorings > -> replace all occurrances of "isNil not" with "notNil" > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 15, 2008

Re: [Pharo-project] Re: Re: Re: Building VM Freetype

by Norbert Hartl

On Mon, 2008-09-15 at 09:53 +0300, Igor Stasenko wrote: > 2008/9/15 Norbert Hartl <norbert(a)hartl.name>: > > On Mon, 2008-09-15 at 03:36 +0300, Igor Stasenko wrote: > >> I managed to build squeak + freetype plugin on my ubuntu box. > >> Not sure, however how to package resulting binary. > >> > > I took a look at the svn repo and there is indeed no other > > option than installing the binary in the system. I wonder how > > the vm is usually packed. The links on squeakvm.org for the redhat > > and debian packages are disabled, too. > > > > I can help building debian packages. Maybe it would be good the check > > in the debian files into svn for easy package creation. > > > yes, > something like > 'make bin-package' > would be cool > > Btw, Ubuntu having a squeak in its binary packages collection, so i > think its better to contact with people who actually did it instead of > repeating doing same. But i can't remember who actually made it. The last one I talked about was Matej Kosik. I'll contact him as I don't remember what we talked about last time :) Norbert

Sept. 15, 2008

Re: [Pharo-project] Re: Re: Re: Building VM Freetype

by Igor Stasenko

2008/9/15 Norbert Hartl <norbert(a)hartl.name>: > On Mon, 2008-09-15 at 03:36 +0300, Igor Stasenko wrote: >> I managed to build squeak + freetype plugin on my ubuntu box. >> Not sure, however how to package resulting binary. >> > I took a look at the svn repo and there is indeed no other > option than installing the binary in the system. I wonder how > the vm is usually packed. The links on squeakvm.org for the redhat > and debian packages are disabled, too. > > I can help building debian packages. Maybe it would be good the check > in the debian files into svn for easy package creation. > yes, something like 'make bin-package' would be cool Btw, Ubuntu having a squeak in its binary packages collection, so i think its better to contact with people who actually did it instead of repeating doing same. But i can't remember who actually made it. > Norbert > > > > _______________________________________________ > 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.

Sept. 15, 2008

Re: [Pharo-project] Re: Re: Re: Building VM Freetype

by Norbert Hartl

On Mon, 2008-09-15 at 03:36 +0300, Igor Stasenko wrote: > I managed to build squeak + freetype plugin on my ubuntu box. > Not sure, however how to package resulting binary. > I took a look at the svn repo and there is indeed no other option than installing the binary in the system. I wonder how the vm is usually packed. The links on squeakvm.org for the redhat and debian packages are disabled, too. I can help building debian packages. Maybe it would be good the check in the debian files into svn for easy package creation. Norbert

Sept. 15, 2008

Re: [Pharo-project] superclass:

by StÃ©phane Ducasse

Ye this is is what I tried also. On Sep 15, 2008, at 12:31 AM, Marcus Denker wrote: > > On 15.09.2008, at 00:24, Marcus Denker wrote: > >> >> On 14.09.2008, at 16:19, StÃ©phane Ducasse wrote: >> >>> Hi >>> >>> is there a way that I can trigger the recompilation of a class >>> when its superclass changes? >>> I tried >>> >>> >>> ComponentLikeModel subclasses >>> do: [:each | each superclass: ComponentLikeModel superclass] >>> >>> but I did not get the recompilation. >>> >> >> >> no idea.. to tired. maybe use the ClassBuilder? I think it's there >> precisely because >> mutating class structure is so easy to get wrong... >> > > Why not just do: > > MorphicModel subclass: #ScrollPane > instanceVariableNames: 'scrollBar scroller retractableScrollBar > scrollBarOnLeft getMenuSelector getMenuTitleSelector scrollBarHidden > hasFocus hScrollBar' > classVariableNames: '' > poolDictionaries: '' > category: 'Morphic-Windows' > > MorphicModel subclass: #TwoWayScrollPane > instanceVariableNames: 'getMenuSelector getMenuTitleSelector > xScrollBar yScrollBar scroller' > classVariableNames: '' > poolDictionaries: '' > category: 'MorphicExtras-Obsolete' > > > this then calls the ClassBuilder to do the migrations. works for me. > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 15, 2008

Re: [Pharo-project] Re: Re: Re: Building VM Freetype

by Igor Stasenko

oh, i forgot. You need to fix freetype plugin (see attachment). There was a header included directly instead using library-defined macro, which makes compiler complain that this header not found. The fix should work fine on all platforms. Please update the freetype plugin in repository . 2008/9/15 Igor Stasenko <siguctua(a)gmail.com>: > I managed to build squeak + freetype plugin on my ubuntu box. > Not sure, however how to package resulting binary. > > I put the config files needed to build VM with freetype on downloads page. > However it not links it with main module, so i had to manually patch > makefile by adding > -lGL -lfreetype to make it happy. > > I will put this into SVN repository (http://squeakvm.org/svn/) in the > main squeak trunk (as soon as Ian will update my password, since i > forgot old one, and can't commit now :). > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 15, 2008

Re: [Pharo-project] Re: Re: Re: Building VM Freetype

by Igor Stasenko

I managed to build squeak + freetype plugin on my ubuntu box. Not sure, however how to package resulting binary. I put the config files needed to build VM with freetype on downloads page. However it not links it with main module, so i had to manually patch makefile by adding -lGL -lfreetype to make it happy. I will put this into SVN repository (http://squeakvm.org/svn/) in the main squeak trunk (as soon as Ian will update my password, since i forgot old one, and can't commit now :). -- Best regards, Igor Stasenko AKA sig.

Sept. 15, 2008

Re: [Pharo-project] superclass:

by Marcus Denker

On 15.09.2008, at 00:24, Marcus Denker wrote: > > On 14.09.2008, at 16:19, StÃ©phane Ducasse wrote: > >> Hi >> >> is there a way that I can trigger the recompilation of a class when >> its superclass changes? >> I tried >> >> >> ComponentLikeModel subclasses >> do: [:each | each superclass: ComponentLikeModel superclass] >> >> but I did not get the recompilation. >> > > > no idea.. to tired. maybe use the ClassBuilder? I think it's there > precisely because > mutating class structure is so easy to get wrong... > Why not just do: MorphicModel subclass: #ScrollPane instanceVariableNames: 'scrollBar scroller retractableScrollBar scrollBarOnLeft getMenuSelector getMenuTitleSelector scrollBarHidden hasFocus hScrollBar' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Windows' MorphicModel subclass: #TwoWayScrollPane instanceVariableNames: 'getMenuSelector getMenuTitleSelector xScrollBar yScrollBar scroller' classVariableNames: '' poolDictionaries: '' category: 'MorphicExtras-Obsolete' this then calls the ClassBuilder to do the migrations. works for me. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 14, 2008

Re: [Pharo-project] superclass:

by Marcus Denker

On 14.09.2008, at 16:19, StÃ©phane Ducasse wrote: > Hi > > is there a way that I can trigger the recompilation of a class when > its superclass changes? > I tried > > > ComponentLikeModel subclasses > do: [:each | each superclass: ComponentLikeModel superclass] > > but I did not get the recompilation. > I think there is no easy way... normally all these mutations are done with the ClassBuilder (e.g. adding an instanceVariable, which requires to recompile all subclasses). directly setting superclass: seems a bit dangerous to me... e.g if I evaluate your code: ComponentLikeModel subclasses do: [:each | each superclass: ComponentLikeModel superclass] nevertheless, ComponentLikeModel subclasses --> {TwoWayScrollPane . ScrollPane} and TwoWayScrollPane superclass --> MorphicModel this is because calling superclass: does not fix the "subclasses", that is, the data is out of sync. this one looks better: ComponentLikeModel subclasses do: [:each | each superclass: ComponentLikeModel superclass. ComponentLikeModel superclass addSubclass: each. ComponentLikeModel removeSubclass: each]. But when I recompile the changed classes, it freezes the system: toRecompile := ComponentLikeModel subclasses. ComponentLikeModel subclasses do: [:each | each superclass: ComponentLikeModel superclass. ComponentLikeModel superclass addSubclass: each. ComponentLikeModel removeSubclass: each]. toRecompile do: [:cls | cls withAllSubclassesDo: [:each | each compileAll]] no idea.. to tired. maybe use the ClassBuilder? I think it's there precisely because mutating class structure is so easy to get wrong... Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 14, 2008

Re: [Pharo-project] how to improve the menus

by David RÃ¶thlisberger

I suggest that we come up with a list of menus of the traditional browser that we should add to OB. I can then take care of implementing them. I don't have the impression that we should just port all these menus of the old browser, as many items never get used anyway. So we should decide what we want and what not. David > Lukas sorry my question was not clearly stated: how can we get some > important menus in OB such as > look for code containing string and a couple of others. > > Stef > > > On Sep 12, 2008, at 11:55 PM, Lukas Renggli wrote: > >>> So who is responsible for the menus in OB? >> >> The menus in the columns come from OB. >> >> The menu in the edit pane comes from Squeak though and certain >> commands are intercepted by OB. I think it would make sense if OB >> changed that and provided the whole menu by itself. >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > >

Sept. 14, 2008

[Pharo-project] [ANN] update 10072

by Marcus Denker

update10072 ----------- -> Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej -> Issue 174: XMLSupport can't be loaded into latest Pharo image -> Issue 52: 7102 ObjectPerformOrSendToFix (M1666) -> Issue 106: 7090 DSAunimplementedCleanup -> Issue 77: 7127 RemoveMappedCollection -> More ifNil: refactorings -> replace all occurrances of "isNil not" with "notNil" -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 14, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

2008/9/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Igor could you publish these changes in Squeaksource? > In what form? Changes include adding ivars to events. This kind of change can't be packaged into MC package. Or can? Also, i found that HostWindowPlugin missing platform sources for unix. At least in trunk SVN branch from which i trying to build VM. So, first before publishing them i need to make sure that they can work w/o HostWindowPluginÑ >>> You should try it. There are much more support for Macs than for >> >> windoze in these changesets. >> I had to add own Win32 specific subclass to make it working on windoze. >> >> My wish behind all of this is to provide clean separation between core >> VM and UI. Then, in Hydra each image could create and manage own >> windows. >> >> I just installed an Ubuntu, lets see how far i can get with building >> squeak VM + freetype on it. I never tried to build squeak on linux, >> but i expect it will be much easier than on windows. > > I hope. > > _______________________________________________ > 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.

Sept. 14, 2008

Re: [Pharo-project] Benchmark 3.9 vs. Pharo

by StÃ©phane Ducasse

Excellent!10% is a lot. Indeed little steps at a time. I'm sure that we can make progress there too. We should this bench to continue to monitor our effort. I imagine also that the font ttc fixes of andreas should also help. Stef > Hi, > > Running the Browser-Bench is interesting: > > time _ 0. > saveMorphs _ self currentWorld submorphs. > 5 timesRepeat:[ > self currentWorld removeAllMorphs. "heh, heh" > time _ time + (Time millisecondsToRun: > [ > 1 to: 10 do: [:i | Browser fullOnClass: SystemDictionary selector: > #abandonSources]. > self currentWorld submorphs do: [:m | m delete. self currentWorld > doOneCycle]]). > ]. > self currentWorld addAllMorphs: saveMorphs. > time/5 asFloat "print it" > > > 3.9: 3088.4 > pha: 2805.6 > > Which means: Pharo is 10% faster in opening browsers :-) > Reason: MVC removal, small performance fixes (e.g. related to > properties), other cleanups > (some things related to Nebraska and Wonderland where removed). > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 14, 2008

Re: [Pharo-project] [ANN] update 10071

by StÃ©phane Ducasse

Cooooooooool! I was fixing my floor this afternoon :( Stef On Sep 14, 2008, at 7:45 PM, Marcus Denker wrote: > update10071 > ----------- > > -> Issue 100: 7154 FixForDebugBlockValueWithArguments > -> Issue 172: show byte code menu item pane is broken > -> Issue 39: 7088 AnimatedMorphfix (M5692) > -> Issue 91: 7143 ValueWithinFix-ar > -> Issue 54: 7104 Morph-intersects-wiz (M6461) > -> Add RBSmallDictionary as SmallDictionary. Add > SmallIdentityDictionary > -> Small Nebraska Removal related to HandMorph: > -> do not test for #hasUserInformation in #needsToBeDrawn > -> remove user-drawing code from HandMorph>>#drawOn: > -> delete HandMorph>>#hasUserInformation > -> fast path for empty extension in Morph>>#borderStyle > -> Remove unsent methods from Player: > -> thumbnailMenuEvt:forMorph:, setFogDensity:, setFogRangeEnd:, > setFogRangeStart:, setFogType: > -> getFogColor, getFogDensity, getFogRangeEnd, getFogRangeStart, > getFogType, setFogColor: > -> Remove unsent Methods: > -> TextStyle>>changeDefaultFontSizeBy: > -> AlignmentMorphBob1>>simpleToggleButtonFor:attribute:help: > -> fix ifNotNil:ifNil: and ifNil:ifNotNil: to use > #valueWithPossibleArgs: (to be consistent with ifNotNil:) > -> comment for #browseAllUnimplementedCalls > -> some refactoring everywhere to use isNil and ifNil: (more to go) > -> Start to remove deprecated methods that where deprecated in 3.9 > -> enable deprecation warnings in postscript. > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 14, 2008

Re: [Pharo-project] Benchmark 3.9 vs. Pharo

by Alexandre Bergel

This is an excellent news!!! Alexandre On 14 Sep 2008, at 19:55, Marcus Denker wrote: > Hi, > > Running the Browser-Bench is interesting: > > time _ 0. > saveMorphs _ self currentWorld submorphs. > 5 timesRepeat:[ > self currentWorld removeAllMorphs. "heh, heh" > time _ time + (Time millisecondsToRun: > [ > 1 to: 10 do: [:i | Browser fullOnClass: SystemDictionary selector: > #abandonSources]. > self currentWorld submorphs do: [:m | m delete. self currentWorld > doOneCycle]]). > ]. > self currentWorld addAllMorphs: saveMorphs. > time/5 asFloat "print it" > > > 3.9: 3088.4 > pha: 2805.6 > > Which means: Pharo is 10% faster in opening browsers :-) > Reason: MVC removal, small performance fixes (e.g. related to > properties), other cleanups > (some things related to Nebraska and Wonderland where removed). > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 14, 2008

[Pharo-project] Benchmark 3.9 vs. Pharo

by Marcus Denker

Hi, Running the Browser-Bench is interesting: time _ 0. saveMorphs _ self currentWorld submorphs. 5 timesRepeat:[ self currentWorld removeAllMorphs. "heh, heh" time _ time + (Time millisecondsToRun: [ 1 to: 10 do: [:i | Browser fullOnClass: SystemDictionary selector: #abandonSources]. self currentWorld submorphs do: [:m | m delete. self currentWorld doOneCycle]]). ]. self currentWorld addAllMorphs: saveMorphs. time/5 asFloat "print it" 3.9: 3088.4 pha: 2805.6 Which means: Pharo is 10% faster in opening browsers :-) Reason: MVC removal, small performance fixes (e.g. related to properties), other cleanups (some things related to Nebraska and Wonderland where removed). Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 14, 2008

[Pharo-project] [ANN] update 10071

by Marcus Denker

update10071 ----------- -> Issue 100: 7154 FixForDebugBlockValueWithArguments -> Issue 172: show byte code menu item pane is broken -> Issue 39: 7088 AnimatedMorphfix (M5692) -> Issue 91: 7143 ValueWithinFix-ar -> Issue 54: 7104 Morph-intersects-wiz (M6461) -> Add RBSmallDictionary as SmallDictionary. Add SmallIdentityDictionary -> Small Nebraska Removal related to HandMorph: -> do not test for #hasUserInformation in #needsToBeDrawn -> remove user-drawing code from HandMorph>>#drawOn: -> delete HandMorph>>#hasUserInformation -> fast path for empty extension in Morph>>#borderStyle -> Remove unsent methods from Player: -> thumbnailMenuEvt:forMorph:, setFogDensity:, setFogRangeEnd:, setFogRangeStart:, setFogType: -> getFogColor, getFogDensity, getFogRangeEnd, getFogRangeStart, getFogType, setFogColor: -> Remove unsent Methods: -> TextStyle>>changeDefaultFontSizeBy: -> AlignmentMorphBob1>>simpleToggleButtonFor:attribute:help: -> fix ifNotNil:ifNil: and ifNil:ifNotNil: to use #valueWithPossibleArgs: (to be consistent with ifNotNil:) -> comment for #browseAllUnimplementedCalls -> some refactoring everywhere to use isNil and ifNil: (more to go) -> Start to remove deprecated methods that where deprecated in 3.9 -> enable deprecation warnings in postscript. -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 14, 2008

[Pharo-project] superclass:

by StÃ©phane Ducasse

Hi is there a way that I can trigger the recompilation of a class when its superclass changes? I tried ComponentLikeModel suclasses do: [:each | each superclass: ComponentLikeModel superclass] but I did not get the recompilation. Stef

Sept. 14, 2008

Re: [Pharo-project] PinMorph and GeeMail* cleanup

by StÃ©phane Ducasse

Thanks I will check that. This is true that I wanted to remove ComponentLikeModel and that it crashed the image when polymorph was loaded. Strange enough I could not reproduce the crash consistently. stef On Sep 14, 2008, at 2:39 PM, Norbert Hartl wrote: > Hi, > > I invoked the pointer finder in 10070 and found a few > things. Code changes are in the attached changeset. > Manual cleanup: > > CustomEventsRegistry at: #scrolledIntoView put: IdentityDictionary > new. > CustomEventsRegistry at: #scrolledOutOfView put: IdentityDictionary > new. > > There is still a reference to GeeMailMorph in the Flaps. I'm > not sure what would be an easy way to remove to reference. Maybe > a manual action would be sufficient But I don't know how to > remove it that way, too :)) > > Norbert > <pinmorph-cleanup.1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 14, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by StÃ©phane Ducasse

Igor could you publish these changes in Squeaksource? >> You should try it. There are much more support for Macs than for > windoze in these changesets. > I had to add own Win32 specific subclass to make it working on > windoze. > > My wish behind all of this is to provide clean separation between core > VM and UI. Then, in Hydra each image could create and manage own > windows. > > I just installed an Ubuntu, lets see how far i can get with building > squeak VM + freetype on it. I never tried to build squeak on linux, > but i expect it will be much easier than on windows. I hope.

Sept. 14, 2008

[Pharo-project] PinMorph and GeeMail* cleanup

by Norbert Hartl

Hi, I invoked the pointer finder in 10070 and found a few things. Code changes are in the attached changeset. Manual cleanup: CustomEventsRegistry at: #scrolledIntoView put: IdentityDictionary new. CustomEventsRegistry at: #scrolledOutOfView put: IdentityDictionary new. There is still a reference to GeeMailMorph in the Flaps. I'm not sure what would be an easy way to remove to reference. Maybe a manual action would be sufficient But I don't know how to remove it that way, too :)) Norbert

Sept. 14, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

2008/9/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > sounds cool > I have the eyes blinking of excitment :) > But I'm on mac :) You should try it. There are much more support for Macs than for windoze in these changesets. I had to add own Win32 specific subclass to make it working on windoze. My wish behind all of this is to provide clean separation between core VM and UI. Then, in Hydra each image could create and manage own windows. I just installed an Ubuntu, lets see how far i can get with building squeak VM + freetype on it. I never tried to build squeak on linux, but i expect it will be much easier than on windows. > Stef > On Sep 14, 2008, at 9:13 AM, Igor Stasenko wrote: > >> Thing was even easier than i first thought. >> >> I installed the changesets from here: >> ftp://ftp.smalltalkconsulting.com/experimental/Ffenestri/ >> >> Ffenestri-b-2-WindowProxies.3.cs >> Ffenestri-b-3-MultiHostWindows-Sunits.1.cs >> Ffenestri-b-3-MultiHostWindows.1.cs >> Ffenestri-b-4-Events-Morphic.1.cs >> >> And did few own changes (see attachment). >> >> It can render morphic in a window created by hostwindow plugin. >> The fix was, to remove a code which ignoring the events from non-main >> window :) >> >> Now, the goal is to create some kind of Display manager, refactor some >> code to associate an instance of PasteUpMorph with Display instance. >> Get rid of all direct references to Display - replace it by self >> defaultDisplay. (or self currentDisplay). >> >> and dispatch event handling & drawing based on targeted window/display. >> I hope someone could help me with that refactoring.. I tried to make a >> batch for replacing Display refs to message send, but failed. I'm not >> very good in refactoring tools.. >> I tried to replace text in all methods with Display: >> (CompiledMethod allInstances select: [:each | each literals >> anySatisfy: [:lit | lit isVariableBinding and: [lit key == #Display] >> ]]) >> But refactoring based on text source is error prone, it would be good >> to use RB refactoring to make it precisely. >> >> >> On windoze almost everything is functional - of course there is some >> visual glitches, but code is stable and not crashing image even when >> you'll save the image with replaced Display! >> >> Try the code yourself. Just file in the changes, and then do: >> >> DisplayHostWindow installAsDisplay >> >> and when you done: >> >> Display uninstall >> >> to revert to usual Display >> >> 2008/9/13 Igor Stasenko <siguctua(a)gmail.com>: >>> >>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: >>>> >>>>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> >>>>>> this sounds interesting. >>>>>> But I think that this is important to still be able to not rely on >>>>>> external >>>>>> libraries when you want. >>>>>> so what is the exact difference between having it for free or optional >>>>>> - ? that you need to implement the primitive on platform where you >>>>>> do >>>>>> not need? >>>>>> - ? that the system is not layered in consequence? >>>>> >>>>> I think both. Having it 'for free' leads developers to think that they >>>>> can use it anytime, anywhere, like in String>>showProgressBar. Which >>>>> from my POV is complete stupidity. And now just check different >>>>> mailing lists and count complains about unable to getting rid of such >>>>> 'free' uses, like asking for user input or showing warnings in >>>>> headless image :) >>>> >>>> sure this is something that we should fix from an infrastructural point >>>> of >>>> view using a notification system. >>>> At the end we should not that PopUpMenu everywhere but only in one place >>>> in >>>> the Plafform >>>> code. >>>> >>>>> I don't want it 'for free', but instead, i want that language should >>>>> ask for it, and then, if VM could provide it - start using it. >>>>> Instead of having 'position & size & fullscreen flag' hanging around >>>>> in VM -obviously, with good design, this should be completely at >>>>> language side. >>>>> >>>>>> Did you check the work made around "ffnestraria" ? >>>>> >>>>> Surely, this could be taken as a initial base for new plugin. >>>>> But, as it reads on http://wiki.squeak.org/squeak/3862 : >>>>> >>>>> This architecture is for the lowest levels of the system, the virtual >>>>> machine and dungeon levels of the image. NO support yet exists for >>>>> Morphic since there is a vast amount of code and class cleanup needed. >>>> >>>> Yes I think that we should go slowly but removing a lot of morphic cruft >>>> will >>>> help. >>>> >>>>> >>>>> Tweak has been our sole higher level target thus far since it is >>>>> somewhat less broken, not to mention the target of our main project >>>>> remit. >>>>> >>>>> Since Pharo now actively adressing different Morphic issues, it would >>>>> be good for those who doing it (hello Gary) to keep this idea in mind. >>>> >>>> Yes >>>> >>>>> On embedded systems you don't have a 'window', you just have a >>>>> display. But on PCs, operating system can provide you many windows , >>>>> which can play role as displays. What is bad, that at language side >>>>> you don't have a notion about this, as well as it don't have notion >>>>> whether keys/mouse are present or not. >>>>> I think this should be represented by concrete classes, which can >>>>> answer things like: >>>>> - hasKeyboard(s) >>>>> - hasMouse(s) >>>>> - hasDisplay >>>>> - hasWindowing >>>>> >>>>> for instance, on windoze, you can use a real display using two >>>>> approached: >>>>> - one can prefer using a display (which covers a whole area of >>>>> screen), and should be allowed to control its resolution (if >>>>> possible). >>>>> - another one can rather use windowing and treat separate native >>>>> windows as separate displays. >>>>> >>>>>> Then what is important is to have good more then proof of concepts. >>>>>> This is sometimes that we would be interested in. >>>>>> >>>>>> Stef >>>>>> >>>>> >>>>> >>> >>> Concerning Display & Forms & BitBlt with connection with host window: >>> We already have everything we need in VM!! >>> The only thing which is required to wire things up. >>> >>> Here is components which need to be merged (to work together): >>> - SurfacePlugin & HostWindowPlugin on VM side >>> - DisplayScreen class need to be refactored to create new host window >>> and ask for its surface (which in own turn should be registered by >>> HostWindowPlugin using SurfacePlugin interface). >>> >>> There are also an example in >>> platforms/Cross/plugins/ExampleSurfacePlugin , how to create & >>> register own surface >>> and how to use it at language side. >>> >>> So, we really can throw out almost all windowing stuff from core VM, >>> leaving HostWindowPlugin to handle things. >>> >>> Initially, i guess, that most changes will affect the Display var and >>> DisplayScreen class. >>> For headless mode , a Display could be replaced by >>> NoDisplayScreen - which simply ignoring all calls >>> LazyDisplayScreen - which sits in Display global var until first >>> drawing attempt, and then creates a window and replacing itself by >>> working DisplayScreen. >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> <HostWindowsDisplay.1.cs>_______________________________________________ >> 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.

Sept. 14, 2008

[Pharo-project] Re: Re: how to load sophie

by Andrew Tween

I am running Sophie on Windows. Perhaps the menus are different on a Mac? "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote in message news:96099EE9-95A6-46C7-B954-ACA5EE36C751@inria.fr... I do not have an exit menu under file :( I took the latest version and I get Stef On Sep 12, 2008, at 9:14 PM, Andrew Tween wrote: > > "StÃ©phane Ducasse" <Stephane.Ducasse(a)inria.fr> wrote > in message > news:7916FF5C-0CA0-4562-A69F-65B4B54C8067@inria.fr ... >> Hi mike >> >> I would like to browse the code but not only from MC but in a real >> image. >> How do I get sophie loaded (even in 3.8 or others). >> In particular I would like to see how URI are used in the code. > > If you don't want to install it all from scratch then... > > If you download Sophie from www.sophieproject.org > (http://www.sophieproject.org/download ) > and run it, then the File>>Exit menu item will close the Sophie > application but leave the Squeak image running so you can open browsers > etc. > > Cheers, > Andy > >> >> Setf > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 14, 2008

[Pharo-project] Re: Re: Re: Building VM Freetype

by Andrew Tween

"Igor Stasenko" <siguctua(a)gmail.com> wrote in message news:4a5f5f320809130714u60fe4d6at851dddf92cea4ffd@mail.gmail.com... >I rebuilt VM with changeset & uploaded it replacing old .zip. > > FreeTypeSettings current > clearBitBltSubPixelAvailable; > bitBltSubPixelAvailable > > prints: true Thanks. Everything is working now Andy > > 2008/9/13 Igor Stasenko > <siguctua(a)gmail.com>: >> 2008/9/13 Andrew Tween <amtween(a)hotmail.com>: >>> Hi, >>> "Igor Stasenko" <siguctua(a)gmail.com> wrote >>> in message >>> news:4a5f5f320809130455h6403bc01ne6f8c7638c02cbde@mail.gmail.com... >>>> >>>> I uploaded the binaries + freetype plugin platform sources under >>>> "squeak VM + freetype" cat: >>>> https://gforge.inria.fr/frs/?group_id=1299 >>> >>> Cool. >>> The FreeType plugin seems to work great. >>> I notice that you have used FreeType 2.3.7 - that's good, the previous >>> plugin used 2.2.1 which is quite old now. >>> >>> However, the sub-pixel anti-aliasing isn't working. >>> This can be tested by evaluating ... >>> >>> FreeTypeSettings current >>> clearBitBltSubPixelAvailable; >>> bitBltSubPixelAvailable >>> >>> It answers true if the new BitBlt combination rule 41 is present and >>> working; false otherwise. >>> >> >>> Did you install FreeTypeBitBltSimulation.1.cs >>> (http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt…) >>> into your VMMaker image? >>> If you did, then it is possible that the changeset isn't compatible with >>> the >>> latest VMMaker, and I'll look into it. >>> >> oh..sorry, i forgot to load the changeset for BitBlt. >> >>> Cheers, >>> Andy >>> >>> >>>> >>>> >>>> -- >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig.

Sept. 14, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by StÃ©phane Ducasse

sounds cool I have the eyes blinking of excitment :) But I'm on mac :) Stef On Sep 14, 2008, at 9:13 AM, Igor Stasenko wrote: > Thing was even easier than i first thought. > > I installed the changesets from here: > ftp://ftp.smalltalkconsulting.com/experimental/Ffenestri/ > > Ffenestri-b-2-WindowProxies.3.cs > Ffenestri-b-3-MultiHostWindows-Sunits.1.cs > Ffenestri-b-3-MultiHostWindows.1.cs > Ffenestri-b-4-Events-Morphic.1.cs > > And did few own changes (see attachment). > > It can render morphic in a window created by hostwindow plugin. > The fix was, to remove a code which ignoring the events from non- > main window :) > > Now, the goal is to create some kind of Display manager, refactor some > code to associate an instance of PasteUpMorph with Display instance. > Get rid of all direct references to Display - replace it by self > defaultDisplay. (or self currentDisplay). > > and dispatch event handling & drawing based on targeted window/ > display. > I hope someone could help me with that refactoring.. I tried to make a > batch for replacing Display refs to message send, but failed. I'm not > very good in refactoring tools.. > I tried to replace text in all methods with Display: > (CompiledMethod allInstances select: [:each | each literals > anySatisfy: [:lit | lit isVariableBinding and: [lit key == #Display] > ]]) > But refactoring based on text source is error prone, it would be good > to use RB refactoring to make it precisely. > > > On windoze almost everything is functional - of course there is some > visual glitches, but code is stable and not crashing image even when > you'll save the image with replaced Display! > > Try the code yourself. Just file in the changes, and then do: > > DisplayHostWindow installAsDisplay > > and when you done: > > Display uninstall > > to revert to usual Display > > 2008/9/13 Igor Stasenko <siguctua(a)gmail.com>: >> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: >>> >>>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> >>>>> this sounds interesting. >>>>> But I think that this is important to still be able to not rely on >>>>> external >>>>> libraries when you want. >>>>> so what is the exact difference between having it for free or >>>>> optional >>>>> - ? that you need to implement the primitive on platform >>>>> where you >>>>> do >>>>> not need? >>>>> - ? that the system is not layered in consequence? >>>> >>>> I think both. Having it 'for free' leads developers to think that >>>> they >>>> can use it anytime, anywhere, like in String>>showProgressBar. >>>> Which >>>> from my POV is complete stupidity. And now just check different >>>> mailing lists and count complains about unable to getting rid of >>>> such >>>> 'free' uses, like asking for user input or showing warnings in >>>> headless image :) >>> >>> sure this is something that we should fix from an infrastructural >>> point of >>> view using a notification system. >>> At the end we should not that PopUpMenu everywhere but only in one >>> place in >>> the Plafform >>> code. >>> >>>> I don't want it 'for free', but instead, i want that language >>>> should >>>> ask for it, and then, if VM could provide it - start using it. >>>> Instead of having 'position & size & fullscreen flag' hanging >>>> around >>>> in VM -obviously, with good design, this should be completely at >>>> language side. >>>> >>>>> Did you check the work made around "ffnestraria" ? >>>> >>>> Surely, this could be taken as a initial base for new plugin. >>>> But, as it reads on http://wiki.squeak.org/squeak/3862 : >>>> >>>> This architecture is for the lowest levels of the system, the >>>> virtual >>>> machine and dungeon levels of the image. NO support yet exists for >>>> Morphic since there is a vast amount of code and class cleanup >>>> needed. >>> >>> Yes I think that we should go slowly but removing a lot of morphic >>> cruft >>> will >>> help. >>> >>>> >>>> Tweak has been our sole higher level target thus far since it is >>>> somewhat less broken, not to mention the target of our main project >>>> remit. >>>> >>>> Since Pharo now actively adressing different Morphic issues, it >>>> would >>>> be good for those who doing it (hello Gary) to keep this idea in >>>> mind. >>> >>> Yes >>> >>>> On embedded systems you don't have a 'window', you just have a >>>> display. But on PCs, operating system can provide you many >>>> windows , >>>> which can play role as displays. What is bad, that at language side >>>> you don't have a notion about this, as well as it don't have notion >>>> whether keys/mouse are present or not. >>>> I think this should be represented by concrete classes, which can >>>> answer things like: >>>> - hasKeyboard(s) >>>> - hasMouse(s) >>>> - hasDisplay >>>> - hasWindowing >>>> >>>> for instance, on windoze, you can use a real display using two >>>> approached: >>>> - one can prefer using a display (which covers a whole area of >>>> screen), and should be allowed to control its resolution (if >>>> possible). >>>> - another one can rather use windowing and treat separate native >>>> windows as separate displays. >>>> >>>>> Then what is important is to have good more then proof of >>>>> concepts. >>>>> This is sometimes that we would be interested in. >>>>> >>>>> Stef >>>>> >>>> >>>> >> >> Concerning Display & Forms & BitBlt with connection with host window: >> We already have everything we need in VM!! >> The only thing which is required to wire things up. >> >> Here is components which need to be merged (to work together): >> - SurfacePlugin & HostWindowPlugin on VM side >> - DisplayScreen class need to be refactored to create new host window >> and ask for its surface (which in own turn should be registered by >> HostWindowPlugin using SurfacePlugin interface). >> >> There are also an example in >> platforms/Cross/plugins/ExampleSurfacePlugin , how to create & >> register own surface >> and how to use it at language side. >> >> So, we really can throw out almost all windowing stuff from core VM, >> leaving HostWindowPlugin to handle things. >> >> Initially, i guess, that most changes will affect the Display var and >> DisplayScreen class. >> For headless mode , a Display could be replaced by >> NoDisplayScreen - which simply ignoring all calls >> LazyDisplayScreen - which sits in Display global var until first >> drawing attempt, and then creates a window and replacing itself by >> working DisplayScreen. >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > <HostWindowsDisplay. > 1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 14, 2008

Re: [Pharo-project] show bytecode menu -> DNU

by StÃ©phane Ducasse

excellent I will harvest after my nap (I'm dead and it is only 12 :( Stef On Sep 14, 2008, at 10:56 AM, Marcus Denker wrote: > > On 12.09.2008, at 20:22, StÃ©phane Ducasse wrote: > >> Hi >> >> if one of you could have a look at the menu item show bytecode. >> > > this one fixes it: > > > > <PluggableTextMorph-showBytecodes.st> > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 14, 2008

Re: [Pharo-project] show bytecode menu -> DNU

by Marcus Denker

On 12.09.2008, at 20:22, StÃ©phane Ducasse wrote: > Hi > > if one of you could have a look at the menu item show bytecode. > this one fixes it: -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 14, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

Thing was even easier than i first thought. I installed the changesets from here: ftp://ftp.smalltalkconsulting.com/experimental/Ffenestri/ Ffenestri-b-2-WindowProxies.3.cs Ffenestri-b-3-MultiHostWindows-Sunits.1.cs Ffenestri-b-3-MultiHostWindows.1.cs Ffenestri-b-4-Events-Morphic.1.cs And did few own changes (see attachment). It can render morphic in a window created by hostwindow plugin. The fix was, to remove a code which ignoring the events from non-main window :) Now, the goal is to create some kind of Display manager, refactor some code to associate an instance of PasteUpMorph with Display instance. Get rid of all direct references to Display - replace it by self defaultDisplay. (or self currentDisplay). and dispatch event handling & drawing based on targeted window/display. I hope someone could help me with that refactoring.. I tried to make a batch for replacing Display refs to message send, but failed. I'm not very good in refactoring tools.. I tried to replace text in all methods with Display: (CompiledMethod allInstances select: [:each | each literals anySatisfy: [:lit | lit isVariableBinding and: [lit key == #Display] ]]) But refactoring based on text source is error prone, it would be good to use RB refactoring to make it precisely. On windoze almost everything is functional - of course there is some visual glitches, but code is stable and not crashing image even when you'll save the image with replaced Display! Try the code yourself. Just file in the changes, and then do: DisplayHostWindow installAsDisplay and when you done: Display uninstall to revert to usual Display 2008/9/13 Igor Stasenko <siguctua(a)gmail.com>: > 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: >> >>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> this sounds interesting. >>>> But I think that this is important to still be able to not rely on >>>> external >>>> libraries when you want. >>>> so what is the exact difference between having it for free or optional >>>> - ? that you need to implement the primitive on platform where you >>>> do >>>> not need? >>>> - ? that the system is not layered in consequence? >>> >>> I think both. Having it 'for free' leads developers to think that they >>> can use it anytime, anywhere, like in String>>showProgressBar. Which >>> from my POV is complete stupidity. And now just check different >>> mailing lists and count complains about unable to getting rid of such >>> 'free' uses, like asking for user input or showing warnings in >>> headless image :) >> >> sure this is something that we should fix from an infrastructural point of >> view using a notification system. >> At the end we should not that PopUpMenu everywhere but only in one place in >> the Plafform >> code. >> >>> I don't want it 'for free', but instead, i want that language should >>> ask for it, and then, if VM could provide it - start using it. >>> Instead of having 'position & size & fullscreen flag' hanging around >>> in VM -obviously, with good design, this should be completely at >>> language side. >>> >>>> Did you check the work made around "ffnestraria" ? >>> >>> Surely, this could be taken as a initial base for new plugin. >>> But, as it reads on http://wiki.squeak.org/squeak/3862 : >>> >>> This architecture is for the lowest levels of the system, the virtual >>> machine and dungeon levels of the image. NO support yet exists for >>> Morphic since there is a vast amount of code and class cleanup needed. >> >> Yes I think that we should go slowly but removing a lot of morphic cruft >> will >> help. >> >>> >>> Tweak has been our sole higher level target thus far since it is >>> somewhat less broken, not to mention the target of our main project >>> remit. >>> >>> Since Pharo now actively adressing different Morphic issues, it would >>> be good for those who doing it (hello Gary) to keep this idea in mind. >> >> Yes >> >>> On embedded systems you don't have a 'window', you just have a >>> display. But on PCs, operating system can provide you many windows , >>> which can play role as displays. What is bad, that at language side >>> you don't have a notion about this, as well as it don't have notion >>> whether keys/mouse are present or not. >>> I think this should be represented by concrete classes, which can >>> answer things like: >>> - hasKeyboard(s) >>> - hasMouse(s) >>> - hasDisplay >>> - hasWindowing >>> >>> for instance, on windoze, you can use a real display using two approached: >>> - one can prefer using a display (which covers a whole area of >>> screen), and should be allowed to control its resolution (if >>> possible). >>> - another one can rather use windowing and treat separate native >>> windows as separate displays. >>> >>>> Then what is important is to have good more then proof of concepts. >>>> This is sometimes that we would be interested in. >>>> >>>> Stef >>>> >>> >>> > > Concerning Display & Forms & BitBlt with connection with host window: > We already have everything we need in VM!! > The only thing which is required to wire things up. > > Here is components which need to be merged (to work together): > - SurfacePlugin & HostWindowPlugin on VM side > - DisplayScreen class need to be refactored to create new host window > and ask for its surface (which in own turn should be registered by > HostWindowPlugin using SurfacePlugin interface). > > There are also an example in > platforms/Cross/plugins/ExampleSurfacePlugin , how to create & > register own surface > and how to use it at language side. > > So, we really can throw out almost all windowing stuff from core VM, > leaving HostWindowPlugin to handle things. > > Initially, i guess, that most changes will affect the Display var and > DisplayScreen class. > For headless mode , a Display could be replaced by > NoDisplayScreen - which simply ignoring all calls > LazyDisplayScreen - which sits in Display global var until first > drawing attempt, and then creates a window and replacing itself by > working DisplayScreen. > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 14, 2008

Re: [Pharo-project] Re: how to load sophie

by StÃ©phane Ducasse

I do not have an exit menu under file :( I took the latest version and I get Stef On Sep 12, 2008, at 9:14 PM, Andrew Tween wrote: > > "StÃ©phane Ducasse" <Stephane.Ducasse(a)inria.fr> wrote in message news:7916FF5C-0CA0-4562-A69F-65B4B54C8067@inria.fr > ... >> Hi mike >> >> I would like to browse the code but not only from MC but in a real >> image. >> How do I get sophie loaded (even in 3.8 or others). >> In particular I would like to see how URI are used in the code. > > If you don't want to install it all from scratch then... > > If you download Sophie from www.sophieproject.org (http://www.sophieproject.org/download > ) > and run it, then the File>>Exit menu item will close the Sophie > application but leave the Squeak image running so you can open > browsers etc. > > Cheers, > Andy > >> >> Setf > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2008

[Pharo-project] [ANN] some updates 10062 -> 10070

by StÃ©phane Ducasse

------------------------------------------------------ update10063 - add #numberOfMethods - fix Behavior>>linesOfCode to be traits-aware - create all morphic events with basicNew to save the send of #initialize - optimized path for Morph>>#fillStyle for emoty morph-extension. (Called a lot) - optimized path for Morph>>#shadowOffset for empy morphExtension (called a lot) - remove call to "self flag #arNote" in Morph>>#transformedFrom: (called on mouse-move) - remove MorphEvent>>#convertFromObsolete - remove turtle trails check from Morph>>#drawOn: - remove more calls to #flag: - some simple code simplification (e.g. call #methods, not #methodDict values, more isEmpty) - remove AbstractEvent>>#saveChangeNotificationAsSARFileWithNumber: ------------------------------------------------------ update10064 -0007136: [BUG] LinkedList add:after: fails to update lastLink -0007156: Behavior>>#initialize sends #superclass: which can cause VM crash - delete #isValidWonderlandTexture - fix TClassAndTraitDescription>>#methods to return the methods of a class or trait - add #localMethods to return methods defined in a class, not included by a trait. -7147 Parser-removeUnusedTemps -0006503: RunArray cant be created through #new: ------------------------------------------------------ update10065 Fixing Transcript and Smalltalk to return themselves when printed :) ------------------------------------------------------ update10066 tally it integration http://bugs.squeak.org/view.php?id=1014 ------------------------------------------------------ update10067 Cleaning html fileout removal http://code.google.com/p/pharo/issues/detail?id=115 ------------------------------------------------------ update10068 - ClassBuilder fixes and tests from Noury Bouraqadi Now instance variable names cannot be uppercased and classVariables lowered. - Refactoring engine tests commented by alexandre bergel to let the test builder work - PackageInfo better printOn: + mostSpecificPackageOf: - Tools package loaded (was forgotten before) with tally enh of alexandre Bergel ------------------------------------------------------ update10070 Remove TextSqkLink TextProjectSqkLink

Sept. 13, 2008

Re: [Pharo-project] About removing TextSqkLink and TextSqkProjectLink

by StÃ©phane Ducasse

I got nervous :) so 10070 removes them :) Stef On Sep 13, 2008, at 4:39 PM, StÃ©phane Ducasse wrote: > Hi guys > > I wanted to know you point of view. > I fall on TextSqkLink and TextSqkProjectLink > that it would be good to remove them. > > What your point of view on that? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2008

[Pharo-project] About removing TextSqkLink and TextSqkProjectLink

by StÃ©phane Ducasse

Hi guys I wanted to know you point of view. I fall on TextSqkLink and TextSqkProjectLink that it would be good to remove them. What your point of view on that? Stef

Sept. 13, 2008

Re: [Pharo-project] Re: Re: Building VM Freetype

by Igor Stasenko

I rebuilt VM with changeset & uploaded it replacing old .zip. FreeTypeSettings current clearBitBltSubPixelAvailable; bitBltSubPixelAvailable prints: true 2008/9/13 Igor Stasenko <siguctua(a)gmail.com>: > 2008/9/13 Andrew Tween <amtween(a)hotmail.com>: >> Hi, >> "Igor Stasenko" <siguctua(a)gmail.com> wrote in message >> news:4a5f5f320809130455h6403bc01ne6f8c7638c02cbde@mail.gmail.com... >>> >>> I uploaded the binaries + freetype plugin platform sources under >>> "squeak VM + freetype" cat: >>> https://gforge.inria.fr/frs/?group_id=1299 >> >> Cool. >> The FreeType plugin seems to work great. >> I notice that you have used FreeType 2.3.7 - that's good, the previous >> plugin used 2.2.1 which is quite old now. >> >> However, the sub-pixel anti-aliasing isn't working. >> This can be tested by evaluating ... >> >> FreeTypeSettings current >> clearBitBltSubPixelAvailable; >> bitBltSubPixelAvailable >> >> It answers true if the new BitBlt combination rule 41 is present and >> working; false otherwise. >> > >> Did you install FreeTypeBitBltSimulation.1.cs >> (http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt…) >> into your VMMaker image? >> If you did, then it is possible that the changeset isn't compatible with the >> latest VMMaker, and I'll look into it. >> > oh..sorry, i forgot to load the changeset for BitBlt. > >> Cheers, >> Andy >> >> >>> >>> >>> -- >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: > >> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> this sounds interesting. >>> But I think that this is important to still be able to not rely on >>> external >>> libraries when you want. >>> so what is the exact difference between having it for free or optional >>> - ? that you need to implement the primitive on platform where you >>> do >>> not need? >>> - ? that the system is not layered in consequence? >> >> I think both. Having it 'for free' leads developers to think that they >> can use it anytime, anywhere, like in String>>showProgressBar. Which >> from my POV is complete stupidity. And now just check different >> mailing lists and count complains about unable to getting rid of such >> 'free' uses, like asking for user input or showing warnings in >> headless image :) > > sure this is something that we should fix from an infrastructural point of > view using a notification system. > At the end we should not that PopUpMenu everywhere but only in one place in > the Plafform > code. > >> I don't want it 'for free', but instead, i want that language should >> ask for it, and then, if VM could provide it - start using it. >> Instead of having 'position & size & fullscreen flag' hanging around >> in VM -obviously, with good design, this should be completely at >> language side. >> >>> Did you check the work made around "ffnestraria" ? >> >> Surely, this could be taken as a initial base for new plugin. >> But, as it reads on http://wiki.squeak.org/squeak/3862 : >> >> This architecture is for the lowest levels of the system, the virtual >> machine and dungeon levels of the image. NO support yet exists for >> Morphic since there is a vast amount of code and class cleanup needed. > > Yes I think that we should go slowly but removing a lot of morphic cruft > will > help. > >> >> Tweak has been our sole higher level target thus far since it is >> somewhat less broken, not to mention the target of our main project >> remit. >> >> Since Pharo now actively adressing different Morphic issues, it would >> be good for those who doing it (hello Gary) to keep this idea in mind. > > Yes > >> On embedded systems you don't have a 'window', you just have a >> display. But on PCs, operating system can provide you many windows , >> which can play role as displays. What is bad, that at language side >> you don't have a notion about this, as well as it don't have notion >> whether keys/mouse are present or not. >> I think this should be represented by concrete classes, which can >> answer things like: >> - hasKeyboard(s) >> - hasMouse(s) >> - hasDisplay >> - hasWindowing >> >> for instance, on windoze, you can use a real display using two approached: >> - one can prefer using a display (which covers a whole area of >> screen), and should be allowed to control its resolution (if >> possible). >> - another one can rather use windowing and treat separate native >> windows as separate displays. >> >>> Then what is important is to have good more then proof of concepts. >>> This is sometimes that we would be interested in. >>> >>> Stef >>> >> >> Concerning Display & Forms & BitBlt with connection with host window: We already have everything we need in VM!! The only thing which is required to wire things up. Here is components which need to be merged (to work together): - SurfacePlugin & HostWindowPlugin on VM side - DisplayScreen class need to be refactored to create new host window and ask for its surface (which in own turn should be registered by HostWindowPlugin using SurfacePlugin interface). There are also an example in platforms/Cross/plugins/ExampleSurfacePlugin , how to create & register own surface and how to use it at language side. So, we really can throw out almost all windowing stuff from core VM, leaving HostWindowPlugin to handle things. Initially, i guess, that most changes will affect the Display var and DisplayScreen class. For headless mode , a Display could be replaced by NoDisplayScreen - which simply ignoring all calls LazyDisplayScreen - which sits in Display global var until first drawing attempt, and then creates a window and replacing itself by working DisplayScreen. -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by StÃ©phane Ducasse

Tx On Sep 13, 2008, at 1:55 PM, Igor Stasenko wrote: > I uploaded the binaries + freetype plugin platform sources under > "squeak VM + freetype" cat: > https://gforge.inria.fr/frs/?group_id=1299 > > > -- > 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 >

Sept. 13, 2008

Re: [Pharo-project] Re: Re: Building VM Freetype

by Igor Stasenko

2008/9/13 Andrew Tween <amtween(a)hotmail.com>: > Hi, > "Igor Stasenko" <siguctua(a)gmail.com> wrote in message > news:4a5f5f320809130455h6403bc01ne6f8c7638c02cbde@mail.gmail.com... >> >> I uploaded the binaries + freetype plugin platform sources under >> "squeak VM + freetype" cat: >> https://gforge.inria.fr/frs/?group_id=1299 > > Cool. > The FreeType plugin seems to work great. > I notice that you have used FreeType 2.3.7 - that's good, the previous > plugin used 2.2.1 which is quite old now. > > However, the sub-pixel anti-aliasing isn't working. > This can be tested by evaluating ... > > FreeTypeSettings current > clearBitBltSubPixelAvailable; > bitBltSubPixelAvailable > > It answers true if the new BitBlt combination rule 41 is present and > working; false otherwise. > > Did you install FreeTypeBitBltSimulation.1.cs > (http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt…) > into your VMMaker image? > If you did, then it is possible that the changeset isn't compatible with the > latest VMMaker, and I'll look into it. > oh..sorry, i forgot to load the changeset for BitBlt. > Cheers, > Andy > > >> >> >> -- >> 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

[Pharo-project] Re: Re: Building VM Freetype

by Andrew Tween

Hi, "Igor Stasenko" <siguctua(a)gmail.com> wrote in message news:4a5f5f320809130455h6403bc01ne6f8c7638c02cbde@mail.gmail.com... >I uploaded the binaries + freetype plugin platform sources under > "squeak VM + freetype" cat: > https://gforge.inria.fr/frs/?group_id=1299 Cool. The FreeType plugin seems to work great. I notice that you have used FreeType 2.3.7 - that's good, the previous plugin used 2.2.1 which is quite old now. However, the sub-pixel anti-aliasing isn't working. This can be tested by evaluating ... FreeTypeSettings current clearBitBltSubPixelAvailable; bitBltSubPixelAvailable It answers true if the new BitBlt combination rule 41 is present and working; false otherwise. Did you install FreeTypeBitBltSimulation.1.cs (http://www.zen61439.zen.co.uk/bak/bitBlt_plugin_enhancements/FreeTypeBitBlt…) into your VMMaker image? If you did, then it is possible that the changeset isn't compatible with the latest VMMaker, and I'll look into it. Cheers, Andy > > > -- > Best regards, > Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by Igor Stasenko

I uploaded the binaries + freetype plugin platform sources under "squeak VM + freetype" cat: https://gforge.inria.fr/frs/?group_id=1299 -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Fwd: [Pharo-project] Re: Building VM Freetype

by StÃ©phane Ducasse

Begin forwarded message: > From: John M McIntosh <johnmci(a)smalltalkconsulting.com> > Date: September 13, 2008 11:28:56 AM CEDT > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: Igor Stasenko <siguctua(a)gmail.com>, Michael Rueger <michael(a)impara.de > > > Subject: Re: [Pharo-project] Re: Building VM Freetype > Reply-To: johnmci(a)smalltalkconsulting.com > > Ok, first we statically loaded any *.dll into the freetype plugin > because we found earlier versions of os-x didn't have > the required version of freetype needed to support what we were > doing, also it was a complete mess on the linux side > with regard to what you would find there if you dynamically loaded > the plugin. > > the freetype plugin source code I have was loaded from http://source.impara.de/freetype > > I see the FT2Constants seems to be shared between the freetype base > package and the plugin package, so it appears you > need to load the base in order for the plugin to load. I'm not sure > anyone noticed this since you need to load the base in order > to test the plugin in any case. > > > On Sep 13, 2008, at 8:59 AM, StÃ©phane Ducasse wrote: > >> >> >> Begin forwarded message: >> >>> From: "Igor Stasenko" <siguctua(a)gmail.com> >>> Date: September 13, 2008 8:24:36 AM CEDT >>> To: "An open mailing list to discuss any topics related to an open- >>> source Smalltalk" <pharo-project(a)lists.gforge.inria.fr> >>> Subject: Re: [Pharo-project] Re: Building VM Freetype >>> Reply-To: An open mailing list to discuss any topics related to an >>> open-source Smalltalk <pharo-project(a)lists.gforge.inria.fr> >>> >>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> I hope other will answer but I thought that we could have a pluggin >>>> and bundle in the deployed packages. >>>> The idea for pharo is to have a similar setup than seaside a one >>>> click app >>>> so the >>>> vm and its plugin would be there (but may be the plugin should >>>> not be in the >>>> image). >>> >>> Plugin is built-in in the VM. But freetype library is coming as >>> separate dynamic library. >>> Is this ok? >>> >>> There can be another option, but it would require to change the >>> plugin >>> code - to not link VM with import lib, but to load freetype.dll on >>> demand. The plugin can simply check if this .dll available and start >>> using it, or if not - fail to initialize, telling the system that >>> plugin functionality is not available. >>> >>>> >>>> Mike or john? On sophie how did you manage that the freetype >>>> bundle could >>>> not be present? >>>> >>> >>> Actually, to build a plugin, you need just headers + freetype.def >>> file >>> which then can be used to >>> create the imports library from it. >>> Building a freetype.dll can be completely separate process. >>> >>> I can remove dependency from freetype.lib, and leave only a >>> freetype.def and create import lib by own, when making VM. >>> But this is not safe, because now you must guarantee that you using >>> correct .dll. (well, you need to guarantee it in either case). >>> >>>> If I remember correctly some people on squeak have been >>>> recompiling it for >>>> 64 bits >>>> >>>>> I done with it. >>>>> The resulting VM will not start without freetype.dll. >>>>> Should i link it statically? But then you should hone their >>>>> license >>>>> stuff... >>>>> >>>>> Also, building freetype on windoze impossible using gnutools which >>>>> used for building VM. >>>>> It's make simply can't understand some things, which i assume >>>>> appear >>>>> in later make versions. >>>>> So, i building freetype using my msys/mingw environment, and then >>>>> simply producing >>>>> - freetype.lib (imports library) >>>>> - freetype.dll >>>>> >>>>> or maybe, i wrong, maybe it can be built using gnutools, but this >>>>> would require too much voodoo dancing. >>>>> it would be cool to make it cleanly build w/o manual work, but >>>>> i'm not >>>>> high expert in makefiles black voodoo. >>>>> >>>>> Okay, who wants the VM? And where i can put the stuff + >>>>> instructions + >>>>> blablabla? >>>> >>>> You can use the code google page for that. >>>> >>>> Stef >>>>> >>>>> >>>>> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>>>>> >>>>>> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>>>>>> >>>>>>> As always, things not working out of the box. >>>>>>> >>>>>>> - VM builds from unzipped VM sources OK >>>>>>> - but for building with VMMaker generated sources, had to fix >>>>>>> 'gnuify' >>>>>>> file to make a clean build >>>>>>> >>>>>>> i dreaming to build vm straight from squeak, without horrid >>>>>>> makefiles. >>>>>>> I heard that Keith did a 'Bob' tool which can be used as a >>>>>>> kind of >>>>>>> make utility. >>>>>>> But i think, to fully replace makefiles, it needs an >>>>>>> OSProcessPlugin >>>>>>> to be able to interact with OS/shell. >>>>>>> >>>>>> >>>>>> Next step, tried to load freetype plugin.... >>>>>> http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz >>>>>> http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz >>>>>> >>>>>> and guess what? YES! It can't be loaded! :) >>>>>> >>>>>> MC complains about following: >>>>>> >>>>>> This package depends on the following classes: >>>>>> FT2Constants >>>>>> >>>>>> The FT2Constants is the pool dictionary used by plugin. But not >>>>>> defined within package. >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> <fonts.jpg>_______________________________________________ >>>>> 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 >> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > >

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by StÃ©phane Ducasse

On Sep 13, 2008, at 10:25 AM, Michael Rueger wrote: > Igor Stasenko wrote: >> ohh... a small correction. >> Not #hasDisplay, but #hasDisplays. >> Which is conceptually VERY important! > > And Ffenestri provides support for that. We actually have something > running (sort of ;-) ) that opens multiple native windows based on > ffenestri. > > I'm all for factoring out the input and display stuff into plugins, > ffenestri is IMHO a good base for that. You can still use bitblt or > balloon for display, so you don't necessarily have to rely on > external libraries as GTK does. So this is good. > > > IIRC the newer VMs already delay opening the window and only do it > on first access, so a first step in the right direction. > > But this, again, raises the question of VM building ;-) yes! > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by StÃ©phane Ducasse

On Sep 13, 2008, at 9:38 AM, Igor Stasenko wrote: > 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> this sounds interesting. >> But I think that this is important to still be able to not rely on >> external >> libraries when you want. >> so what is the exact difference between having it for free or >> optional >> - ? that you need to implement the primitive on platform >> where you do >> not need? >> - ? that the system is not layered in consequence? > > I think both. Having it 'for free' leads developers to think that they > can use it anytime, anywhere, like in String>>showProgressBar. Which > from my POV is complete stupidity. And now just check different > mailing lists and count complains about unable to getting rid of such > 'free' uses, like asking for user input or showing warnings in > headless image :) sure this is something that we should fix from an infrastructural point of view using a notification system. At the end we should not that PopUpMenu everywhere but only in one place in the Plafform code. > I don't want it 'for free', but instead, i want that language should > ask for it, and then, if VM could provide it - start using it. > Instead of having 'position & size & fullscreen flag' hanging around > in VM -obviously, with good design, this should be completely at > language side. > >> Did you check the work made around "ffnestraria" ? > > Surely, this could be taken as a initial base for new plugin. > But, as it reads on http://wiki.squeak.org/squeak/3862 : > > This architecture is for the lowest levels of the system, the virtual > machine and dungeon levels of the image. NO support yet exists for > Morphic since there is a vast amount of code and class cleanup needed. Yes I think that we should go slowly but removing a lot of morphic cruft will help. > > Tweak has been our sole higher level target thus far since it is > somewhat less broken, not to mention the target of our main project > remit. > > Since Pharo now actively adressing different Morphic issues, it would > be good for those who doing it (hello Gary) to keep this idea in mind. Yes > On embedded systems you don't have a 'window', you just have a > display. But on PCs, operating system can provide you many windows , > which can play role as displays. What is bad, that at language side > you don't have a notion about this, as well as it don't have notion > whether keys/mouse are present or not. > I think this should be represented by concrete classes, which can > answer things like: > - hasKeyboard(s) > - hasMouse(s) > - hasDisplay > - hasWindowing > > for instance, on windoze, you can use a real display using two > approached: > - one can prefer using a display (which covers a whole area of > screen), and should be allowed to control its resolution (if > possible). > - another one can rather use windowing and treat separate native > windows as separate displays. > >> Then what is important is to have good more then proof of concepts. >> This is sometimes that we would be interested in. >> >> Stef >> > > > -- > 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

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

2008/9/13 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: >> >> ohh... a small correction. >> Not #hasDisplay, but #hasDisplays. >> >> Which is conceptually VERY important! > > And Ffenestri provides support for that. We actually have something running > (sort of ;-) ) that opens multiple native windows based on ffenestri. > > I'm all for factoring out the input and display stuff into plugins, > ffenestri is IMHO a good base for that. You can still use bitblt or balloon > for display, so you don't necessarily have to rely on external libraries as > GTK does. > Right, a good factored code should rely on a basic OS functionality provided. There is no need in extra dependencies on that. > IIRC the newer VMs already delay opening the window and only do it on first > access, so a first step in the right direction. > Yeah, but i would prefer to receive a direct instruction from language side to open window/display. And if any code tries to talk or draw things w/o asking anyone if it possible at all, then it should be beaten by exceptions. > But this, again, raises the question of VM building ;-) > Well, i think most of work is on language side, not in VM. First we should consider a model, which can be employed to represent an abstract layer for display and user input. Then, based on it, we can determine a set of primitives required to support such model. > Michael > > _______________________________________________ > 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.

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Michael Rueger

Igor Stasenko wrote: > ohh... a small correction. > Not #hasDisplay, but #hasDisplays. > > Which is conceptually VERY important! And Ffenestri provides support for that. We actually have something running (sort of ;-) ) that opens multiple native windows based on ffenestri. I'm all for factoring out the input and display stuff into plugins, ffenestri is IMHO a good base for that. You can still use bitblt or balloon for display, so you don't necessarily have to rely on external libraries as GTK does. IIRC the newer VMs already delay opening the window and only do it on first access, so a first step in the right direction. But this, again, raises the question of VM building ;-) Michael

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Alexandre Bergel

Hi Igor, I like your idea very much. This is what a modular should be. This is exactly the way Squeak-GTK is taking. I am waiting for Gwenael to have a version that runs on MacOSX... Cheers, Alexandre On 13 Sep 2008, at 08:58, Igor Stasenko wrote: > Hello, > > i'd like to discuss with you this quite radical idea. > I , in particular, not happy that windowing in squeak VM is mandatory. > Sure, you can run VM with -headless (or whatever), but this actually > not solving anything, since > VM still in much of control, how to deal with squeak window and how to > manage messages etc. > > What i would like to see, is to completely detach windowing > functionality into a separate VM plugin, making sure that: > a) VM can be built w/o this plugin > b) a language side is in total control to decide whether create and > use window & display or not. > > This would require to deprecate some of 'blue book' primitives, which > coming as built-in VM features , such as: > - displayBits & friends > - fullDisplayUpdate > - keyboard & mouse event handling > > The point is, that squeak grew out on many platforms and embedded > devices. Some of them don't have a usual input devices, like keyboard > & mouse, so it is completely pointless to require VM to support I/O > with these devices as mandatory option. > Same for display. I would be happy to have full control at language > side whether i need display or not , instead of having it 'for free' > from a start and then using workarounds to not show/use it using > command line (while language side still thinks its present). > > > -- > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by Alexandre Bergel

>> Plugin is built-in in the VM. But freetype library is coming as >> separate dynamic library. >> Is this ok? >> >> There can be another option, but it would require to change the >> plugin >> code - to not link VM with import lib, but to load freetype.dll on >> demand. The plugin can simply check if this .dll available and start >> using it, or if not - fail to initialize, telling the system that >> plugin functionality is not available. > > I'm convinced that I'm not an expert here. I have the impression > that the second > option is better, May be we should wait for other feedback on the > idea. I do not think Pharo's users will mind to use a different VM or add a .dll beside their VM. Feel free to chose the simplest way for you, and do not hesitate to ask for feedback. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

ohh... a small correction. Not #hasDisplay, but #hasDisplays. Which is conceptually VERY important! -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by Igor Stasenko

2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > this sounds interesting. > But I think that this is important to still be able to not rely on external > libraries when you want. > so what is the exact difference between having it for free or optional > - ? that you need to implement the primitive on platform where you do > not need? > - ? that the system is not layered in consequence? I think both. Having it 'for free' leads developers to think that they can use it anytime, anywhere, like in String>>showProgressBar. Which from my POV is complete stupidity. And now just check different mailing lists and count complains about unable to getting rid of such 'free' uses, like asking for user input or showing warnings in headless image :) I don't want it 'for free', but instead, i want that language should ask for it, and then, if VM could provide it - start using it. Instead of having 'position & size & fullscreen flag' hanging around in VM -obviously, with good design, this should be completely at language side. > Did you check the work made around "ffnestraria" ? Surely, this could be taken as a initial base for new plugin. But, as it reads on http://wiki.squeak.org/squeak/3862 : This architecture is for the lowest levels of the system, the virtual machine and dungeon levels of the image. NO support yet exists for Morphic since there is a vast amount of code and class cleanup needed. Tweak has been our sole higher level target thus far since it is somewhat less broken, not to mention the target of our main project remit. Since Pharo now actively adressing different Morphic issues, it would be good for those who doing it (hello Gary) to keep this idea in mind. On embedded systems you don't have a 'window', you just have a display. But on PCs, operating system can provide you many windows , which can play role as displays. What is bad, that at language side you don't have a notion about this, as well as it don't have notion whether keys/mouse are present or not. I think this should be represented by concrete classes, which can answer things like: - hasKeyboard(s) - hasMouse(s) - hasDisplay - hasWindowing for instance, on windoze, you can use a real display using two approached: - one can prefer using a display (which covers a whole area of screen), and should be allowed to control its resolution (if possible). - another one can rather use windowing and treat separate native windows as separate displays. > Then what is important is to have good more then proof of concepts. > This is sometimes that we would be interested in. > > Stef > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by StÃ©phane Ducasse

done I added you as admin. You will see that the interface is crap but... Stef On Sep 13, 2008, at 9:06 AM, Igor Stasenko wrote: > 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Sorry that you refer to just instruction. >> Then I would suggest that you register to the fgorge.inria.fr >> use team ADAM when creating yur account >> once you have done that I will add you to the pharo project >> then we will be able to use the svn and >> the uploads >> > done. > login: sig >> Stef >> >> >> On Sep 13, 2008, at 8:36 AM, Igor Stasenko wrote: >> >>> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>>>> Okay, who wants the VM? And where i can put the stuff + >>>>> instructions + >>>>> blablabla? >>>> >>>> You can use the code google page for that. >>> >>> Can you be more specific? >>> After reading through http://code.google.com/p/pharo/ >>> can't find any directions, where i can put a pre-built VM, or do any >>> upload. I doubt that pharo inbox at squeaksource is appropriate >>> place >>> for VM binaries. >>> >>>> >>>> Stef >>> >>> >>> -- >>> 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 >> > > > > -- > 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

Sept. 13, 2008

Re: [Pharo-project] Throwing out the windowing support from core VM features

by StÃ©phane Ducasse

this sounds interesting. But I think that this is important to still be able to not rely on external libraries when you want. so what is the exact difference between having it for free or optional - ? that you need to implement the primitive on platform where you do not need? - ? that the system is not layered in consequence? Did you check the work made around "ffnestraria" ? Then what is important is to have good more then proof of concepts. This is sometimes that we would be interested in. Stef On Sep 13, 2008, at 8:58 AM, Igor Stasenko wrote: > Hello, > > i'd like to discuss with you this quite radical idea. > I , in particular, not happy that windowing in squeak VM is mandatory. > Sure, you can run VM with -headless (or whatever), but this actually > not solving anything, since > VM still in much of control, how to deal with squeak window and how to > manage messages etc. > > What i would like to see, is to completely detach windowing > functionality into a separate VM plugin, making sure that: > a) VM can be built w/o this plugin > b) a language side is in total control to decide whether create and > use window & display or not. > > This would require to deprecate some of 'blue book' primitives, which > coming as built-in VM features , such as: > - displayBits & friends > - fullDisplayUpdate > - keyboard & mouse event handling > > The point is, that squeak grew out on many platforms and embedded > devices. Some of them don't have a usual input devices, like keyboard > & mouse, so it is completely pointless to require VM to support I/O > with these devices as mandatory option. > Same for display. I would be happy to have full control at language > side whether i need display or not , instead of having it 'for free' > from a start and then using workarounds to not show/use it using > command line (while language side still thinks its present). > > > -- > 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 >

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by Igor Stasenko

2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Sorry that you refer to just instruction. > Then I would suggest that you register to the fgorge.inria.fr > use team ADAM when creating yur account > once you have done that I will add you to the pharo project > then we will be able to use the svn and > the uploads > done. login: sig > Stef > > > On Sep 13, 2008, at 8:36 AM, Igor Stasenko wrote: > >> 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>>> Okay, who wants the VM? And where i can put the stuff + instructions + >>>> blablabla? >>> >>> You can use the code google page for that. >> >> Can you be more specific? >> After reading through http://code.google.com/p/pharo/ >> can't find any directions, where i can put a pre-built VM, or do any >> upload. I doubt that pharo inbox at squeaksource is appropriate place >> for VM binaries. >> >>> >>> Stef >> >> >> -- >> 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 13, 2008

Re: [Pharo-project] Re: Building VM Freetype

by StÃ©phane Ducasse

On Sep 13, 2008, at 8:24 AM, Igor Stasenko wrote: > 2008/9/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I hope other will answer but I thought that we could have a pluggin >> and bundle in the deployed packages. >> The idea for pharo is to have a similar setup than seaside a one >> click app >> so the >> vm and its plugin would be there (but may be the plugin should not >> be in the >> image). > > Plugin is built-in in the VM. But freetype library is coming as > separate dynamic library. > Is this ok? > > There can be another option, but it would require to change the plugin > code - to not link VM with import lib, but to load freetype.dll on > demand. The plugin can simply check if this .dll available and start > using it, or if not - fail to initialize, telling the system that > plugin functionality is not available. I'm convinced that I'm not an expert here. I have the impression that the second option is better, May be we should wait for other feedback on the idea. Stef > > >> >> Mike or john? On sophie how did you manage that the freetype bundle >> could >> not be present? >> > > Actually, to build a plugin, you need just headers + freetype.def file > which then can be used to > create the imports library from it. > Building a freetype.dll can be completely separate process. > > I can remove dependency from freetype.lib, and leave only a > freetype.def and create import lib by own, when making VM. > But this is not safe, because now you must guarantee that you using > correct .dll. (well, you need to guarantee it in either case). > >> If I remember correctly some people on squeak have been recompiling >> it for >> 64 bits >> >>> I done with it. >>> The resulting VM will not start without freetype.dll. >>> Should i link it statically? But then you should hone their license >>> stuff... >>> >>> Also, building freetype on windoze impossible using gnutools which >>> used for building VM. >>> It's make simply can't understand some things, which i assume appear >>> in later make versions. >>> So, i building freetype using my msys/mingw environment, and then >>> simply producing >>> - freetype.lib (imports library) >>> - freetype.dll >>> >>> or maybe, i wrong, maybe it can be built using gnutools, but this >>> would require too much voodoo dancing. >>> it would be cool to make it cleanly build w/o manual work, but i'm >>> not >>> high expert in makefiles black voodoo. >>> >>> Okay, who wants the VM? And where i can put the stuff + >>> instructions + >>> blablabla? >> >> You can use the code google page for that. >> >> Stef >>> >>> >>> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>>> >>>> 2008/9/12 Igor Stasenko <siguctua(a)gmail.com>: >>>>> >>>>> As always, things not working out of the box. >>>>> >>>>> - VM builds from unzipped VM sources OK >>>>> - but for building with VMMaker generated sources, had to fix >>>>> 'gnuify' >>>>> file to make a clean build >>>>> >>>>> i dreaming to build vm straight from squeak, without horrid >>>>> makefiles. >>>>> I heard that Keith did a 'Bob' tool which can be used as a kind of >>>>> make utility. >>>>> But i think, to fully replace makefiles, it needs an >>>>> OSProcessPlugin >>>>> to be able to interact with OS/shell. >>>>> >>>> >>>> Next step, tried to load freetype plugin.... >>>> http://source.impara.de/freetype/Freetype-Plugin-JMM.53.mcz >>>> http://source.impara.de/freetype/Freetype-Plugin-tween.51.mcz >>>> >>>> and guess what? YES! It can't be loaded! :) >>>> >>>> MC complains about following: >>>> >>>> This package depends on the following classes: >>>> FT2Constants >>>> >>>> The FT2Constants is the pool dictionary used by plugin. But not >>>> defined within package. >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> <fonts.jpg>_______________________________________________ >>> 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

Sept. 13, 2008