- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN 1.3] pre-build Core 1.3a#13021

by StÃ©phane Ducasse

excellent process. the ultimate release process. Stef On Jan 27, 2011, at 10:52 AM, Marcus Denker wrote: > > On Jan 27, 2011, at 10:50 AM, StÃ©phane Ducasse wrote: > >> Marcus I like the idea of have 1.3 green all the time. >> So we should move in bug entry the tests that are red. >> > > Yes, and I want to tag "1.3" just those entries that > > -> are ready for inclusion > -> are showstoppers and failing tests > > The idea is that the daily build should be as close as possible to a release. > (a release should consist of pressing one button, with *everything* automatized). > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

Jan. 27, 2011

Re: [Pharo-project] [ANN 1.3] pre-build Core 1.3a#13021

by laurent laffont

Shouldn't we have Pharo 1.3 (Dev) added on Hudson too ? Early feeback seems better to me. Laurent On Thu, Jan 27, 2011 at 10:49 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Marcus I like the idea of have 1.3 green all the time. > So we should move in bug entry the tests that are red. > > Stef > > On Jan 27, 2011, at 10:40 AM, Marcus Denker wrote: > > > > > > https://gforge.inria.fr/frs/download.php/28188/PharoCore-1.3-13021.zip > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > >

Jan. 27, 2011

Re: [Pharo-project] [ANN 1.3] pre-build Core 1.3a#13021

by Marcus Denker

On Jan 27, 2011, at 10:50 AM, StÃ©phane Ducasse wrote: > Marcus I like the idea of have 1.3 green all the time. > So we should move in bug entry the tests that are red. > Yes, and I want to tag "1.3" just those entries that -> are ready for inclusion -> are showstoppers and failing tests The idea is that the daily build should be as close as possible to a release. (a release should consist of pressing one button, with *everything* automatized). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 27, 2011

Re: [Pharo-project] About FileSystem (probably not for 1.3)

by StÃ©phane Ducasse

On Jan 27, 2011, at 10:06 AM, Max Leske wrote: > I had to make some changes / additions (only very few though) to Filesystem myself. You can find the changes here: http://www.squeaksource.com/GitFS. A few of the changes have been integrated into the main branch by Lukas I think. > I'd be happy to help with Filesystem especially since I've worked with it quite a bit. Unfortunately, I won't have time for another three or four weeks. Anyway, I'll keep following this thread. I'd really like to see a refined version of Filesystem pushed into Pharo. Thanks I will merge your changes first. For example I do not like filesystem workingDirectory isWorkingDirectory returns false so workingDirectory should be renamed workingPath and FS... workingDirectory -> should be as current workingDirectory I started to add comments as far as I could understand the library. I will read the tests and probably will write new ones to document what I understand. > > Max > > > On 27.01.2011, at 09:59, Igor Stasenko wrote: > >> On 26 January 2011 21:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Hi guys, >>> >>> I was checking the state of FileSystem and we cannot push it into pharo like that! >>> Sad but we should not put code where not a single method has a comment. >>> So instead of crying and bashing colin, I started a while ago to understand (great pain) >>> and write comments probably wrong, of course. Now I did several iterations but not enough. >>> So I will read the blog entries of lukas and try to continue. >>> >> >>> http://www.lukas-renggli.ch/blog/filesystem >>> >>> Now if you want pharo to evolve, then this is clearly a place to help. We should get better class comments, >>> and all the methods with a comment. Else FileSystem will not get integrated. I will veto it. >>> >> >> Is it incomplete , or it just not well documented? I understand that >> new things require documentation because people won't know how to use >> it, >> but what about functionality? >> >>> Colin lost all the changes he did after ESUG so we will have to live with that (for example >>> FSPath not being a class for public consumption and others). >>> >>> Stef >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >

Jan. 27, 2011

Re: [Pharo-project] [ANN 1.3] pre-build Core 1.3a#13021

by StÃ©phane Ducasse

Marcus I like the idea of have 1.3 green all the time. So we should move in bug entry the tests that are red. Stef On Jan 27, 2011, at 10:40 AM, Marcus Denker wrote: > > https://gforge.inria.fr/frs/download.php/28188/PharoCore-1.3-13021.zip > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

Jan. 27, 2011

Re: [Pharo-project] Issue 3601 in pharo: Recommended Seaside version in Pharo-1.2 outdated

by pharo＠googlecode.com

Comment #1 on issue 3601 by Torsten....(a)astares.de: Recommended Seaside version in Pharo-1.2 outdated http://code.google.com/p/pharo/issues/detail?id=3601 Seaside loads and runs when I use the 3.0.3 version: ((Smalltalk at: #ConfigurationOfSeaside30) project version: '3.0.0-alpha5.15') load. but I get 5 failing tests (WAFileLibraryTest and WAPharoFileLibraryTest fail) since GRPharoPlatform>>useByteArrayLiterals uses "Preferences": useByteArrayLiterals "whether ByteArray literals can/should be used" ^Preferences valueOfFlag: #compileUseNewCompiler ifAbsent: [ false ] and there is WAPharoLibraryTest>>hasNewCompiler too: hasNewCompiler Preferences valueOfFlag: #compileUseNewCompiler ifAbsent: [ ^false ]. ^true and there is a (IMHO redundant) WAPharoLibraryTest>>compileUseNewCompiler: compileUseNewCompiler ^Preferences valueOfFlag: #compileUseNewCompiler ifAbsent: [ false ]

Jan. 27, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #12 on issue 3583 by Benjamin...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 Shout is not a part of the Core, so I think we can live without text shouting ^^ For dev image, it could be cool to have it because code colorization is really helpful. But I think it's not long to fix, but I have to work on Hazel this week :) I will try to take a look this week end

Jan. 27, 2011

[Pharo-project] [ANN 1.3] pre-build Core 1.3a#13021

by Marcus Denker

https://gforge.inria.fr/frs/download.php/28188/PharoCore-1.3-13021.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 27, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #11 on issue 3583 by marcus.d...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 Question1: does this touch Core code or Package in Full? Question: Is this a show-stopper for a 1.2 release? Meaning: Could we live wiithout it until a 1.2.1?

Jan. 27, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #10 on issue 3583 by Benjamin...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 the next step should be to change class which actually need shout, and to specify their UI to styled the text. I'll take a look as soon as I have enough time :)

Jan. 27, 2011