March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Filesystem and FS extensions in Pharo book

by StÃ©phane Ducasse

what we should do is also to merge our changes in the latest version of colin ;( but we should move on that front too. Stef On Mar 23, 2011, at 9:02 AM, Max Leske wrote: > Ok, will do. > > Max > > > On 22.03.2011, at 18:54, StÃ©phane Ducasse wrote: > >> Max if you want to help what you can do is to have a look at the Filesystem chapter in the pharo by example vol 2 on github. >> We will update it and probably should do several passes on the chapter anyway. >> Stef >> >> >> >>> Yes, I understand that. My question is if I should create entries for the "old" version since that one is working and has working extensions. >>> >>> Max >>> >>> >>> On 22.03.2011, at 13:37, StÃ©phane Ducasse wrote: >>> >>>> right now we are stuck because we started documenting and understanding FS and coling publihsed a new one and he should merge our changes >>>> >>>> Stef >>>> >>>> On Mar 22, 2011, at 1:20 PM, Max Leske wrote: >>>> >>>>> Hey >>>>> >>>>> I miss Filesystem and its extensions (cURL, zip, git etc.) in the Pharo book. I'd write the entries but I want your oppinion on whether we should wait till the Filesystem rewrite in 1.2 is ready. >>>>> >>>>> My suggestion: >>>>> >>>>> ---- Pharo Tools >>>>> ---- ---- Filesystem >>>>> ---- ---- ---- Filesystem for Pharo 1.1 >>>>> ---- ---- ---- ---- extensions 1 ...n >>>>> ---- ---- ---- Filesystem for Pharo 1.2 >>>>> ---- ---- ---- ---- extensions 1 ...n >>>>> >>>>> Should we even list the "old" versions? The downside to that is that we would have to wait for all the extensions to be updated. >>>>> What do you think? >>>>> >>>>> Max >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

March 23, 2011

Re: [Pharo-project] Pharo 1.2 red again

by Panu Suominen

I am quite sure that you already know all of this, but I just have urge to make some noice. :) In Java world Maven handles this situation using term snapshot dependency. Non-snapshot release can/should not contain any snapshot dependencies. Contents of snapshot version is expected to change and non-snapshot releases are supposed to remain static. To me it looks like that these stable & co symbolic versions are quite the same than Mavens snapshot versions. Thus I think it would make sense have a functionality in metacello to "release" a version which would use the exact versions instead of symbolic ones. At least there there should be validation agains these issues. Possibly it should lock the monticello packages used to load the configurations also. IMHO it breaks the whole if so called stable version of project A depends on some other project which uses some symbolic version of some third project. When this third project advances it will eventually break the project A and thus the B in between does not seem so stable anymore. 2011/3/23 Dale Henrichs <dhenrich(a)vmware.com>: > Miguel, > > Two things: > > Â 1) there are certain conditions where #stable is the correct version to use > Â 2) I thought the point of running hudson-based tests is to identify these types > Â Â Â of problems as soon as they occur so that they can be fixed earlier. > > With that said, I'd be inclined to create some scripts that recorded the "configuration signature" of an image, something like the following: > > Â - Nile 1.2 (GuillermoPolito.19) > Â - OCompletion 1.2.2 (GuillermePolito.39) > Â - Pharo 1.1.1 (LaurentLaffonte.148) > Â - .... > > where the parenthesized info is the author and version of the mcz file. So if an error shows up out of the blue, the first thing would be to check for changes in the "configuration signature" and go from there ... > > We're already doing this kind of thing for the MetacelloBrowser, so it would be very easy to whip up a script to build the signature ... I guess each image could keep/generate it's signature.... > > I think the "configuration signature" is very useful ... if the "configuration signature" doesn't change the exact same code should be loaded ... > > Dale > > > On Mar 23, 2011, at 8:40 AM, Miguel CobÃ¡ wrote: > >> Maybe we should ask Dale when time permits to add functionality to >> Metacello so that can check all the dependencies for a given >> configuration and make sure (or raise some warning in the validation) >> that some dependency is refered by a symbolic non numeric version (like >> #stable, #latestVersion, #bleedingEdge) so that this validation can be >> run by hudson also and verify that all the configurations are frozen to >> a given number and no dependent on a symbolic version that can change >> anytime after release of Pharo when a package get a new (#stable for >> example) version. >> >> Cheers >> >> El miÃ©, 23-03-2011 a las 13:26 +0100, Marcus Denker escribiÃ³: >>> On Mar 23, 2011, at 12:52 PM, Torsten Bergmann wrote: >>> >>>> Pharo 1.2 is red again! >>>> >>>> DuplicatedVariableError: stylingActive is already defined in Workspace >>>> >>>> https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/195/ >>> >>> >>> We really need to make sure that the config does not load code if we don't explicitly say so. >>> >>> So what code was changed? Why was it loaded? >>> >>> >>> -- >>> Marcus Denker Â -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >> >> -- >> Miguel CobÃ¡ >> http://twitter.com/MiguelCobaMtz >> http://miguel.leugim.com.mx >> >> >> >> > > > -- Panu

March 23, 2011

[Pharo-project] double click highlighting problem with quotation marks

by DougEdmunds

Double clicking just to the left of a closing brace/bracket/parenthesis etc normally goes backwards, finds the opening brace/bracket/parenthesis and highlights the material between them. It does not work correctly if the character immediately before the closing mark is a single or double quotation mark. Instead it always goes forward from the quotation mark to try to find another quotation mark further in the text. File ExampleClass.st 'From Pharo1.2 of 14 March 2011 [Latest update: #12341] on 23 March 2011 at 11:16:26 am'! Object subclass: #ExampleClass instanceVariableNames: 'content owner' classVariableNames: '' poolDictionaries: '' category: 'Sandbox'! !ExampleClass methodsFor: 'as yet unclassified' stamp: 'DougEdmunds 3/23/2011 11:16'! testMessage | a b c d| a := #( 1 2 (3 4 'test 1') 'test 2'). "click just before last closing parens" b := 'test 3'. c := #( 1 2 (3 4 'test 4') 'test 5' ). "click just before last closing parens" d := 'test 6'. ! ! -- View this message in context: http://forum.world.st/double-click-highlighting-problem-with-quotation-mark… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 23, 2011

[Pharo-project] [COTDC] 35 - MCPackageCache

by laurent laffont

Today: MCPackageCache Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

March 23, 2011

Re: [Pharo-project] [COTDC] 34#2 - MCStWriter

by laurent laffont

Final one: = MCStWriter = I write Category/Classes/Methods/.... definitions into Monticello source.stfile format found in .mcz packages. See also MCStReader Example: String streamContents: [:aStream| |writer| writer := MCStWriter on: aStream. writer writeDefinitions: {True asClassDefinition. False asClassDefinition}. ] = MCStReader = I read Category/Classes/Methodes/.... definitions from Monticello source.stfile format. See also MCStWriter. Example: |source| source := String streamContents: [:aStream| |writer| writer := MCStWriter on: aStream. writer writeDefinitions: {True asClassDefinition. False asClassDefinition}. ]. (MCStReader on: source readStream) definitions explore. Laurent On Tue, Mar 22, 2011 at 6:40 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > On Tue, Mar 22, 2011 at 6:20 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> Today: MCStWriter >> > > I write Category/Classes/Methods/.... definitions into Monticello > source.st file format found in .mcz packages. > > Example: > > String streamContents: [:aStream| |writer| > writer := MCStWriter on: aStream. > writer writeDefinitions: {True asClassDefinition. False > asClassDefinition}. > ] > > > Laurent. > > >> >> >> Comment Of The Day Contest - One Day One Comment >> Rules: >> #1: Each day a not commented class is elected. Each day the best comment >> will be integrated with name of the author(s). >> #2: If you cannot comment it, deprecate it. >> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> >> Laurent >> > >

March 23, 2011

Re: [Pharo-project] Pharo 1.2 red again

by Dale Henrichs

Miguel, Two things: 1) there are certain conditions where #stable is the correct version to use 2) I thought the point of running hudson-based tests is to identify these types of problems as soon as they occur so that they can be fixed earlier. With that said, I'd be inclined to create some scripts that recorded the "configuration signature" of an image, something like the following: - Nile 1.2 (GuillermoPolito.19) - OCompletion 1.2.2 (GuillermePolito.39) - Pharo 1.1.1 (LaurentLaffonte.148) - .... where the parenthesized info is the author and version of the mcz file. So if an error shows up out of the blue, the first thing would be to check for changes in the "configuration signature" and go from there ... We're already doing this kind of thing for the MetacelloBrowser, so it would be very easy to whip up a script to build the signature ... I guess each image could keep/generate it's signature.... I think the "configuration signature" is very useful ... if the "configuration signature" doesn't change the exact same code should be loaded ... Dale On Mar 23, 2011, at 8:40 AM, Miguel CobÃ¡ wrote: > Maybe we should ask Dale when time permits to add functionality to > Metacello so that can check all the dependencies for a given > configuration and make sure (or raise some warning in the validation) > that some dependency is refered by a symbolic non numeric version (like > #stable, #latestVersion, #bleedingEdge) so that this validation can be > run by hudson also and verify that all the configurations are frozen to > a given number and no dependent on a symbolic version that can change > anytime after release of Pharo when a package get a new (#stable for > example) version. > > Cheers > > El miÃ©, 23-03-2011 a las 13:26 +0100, Marcus Denker escribiÃ³: >> On Mar 23, 2011, at 12:52 PM, Torsten Bergmann wrote: >> >>> Pharo 1.2 is red again! >>> >>> DuplicatedVariableError: stylingActive is already defined in Workspace >>> >>> https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/195/ >> >> >> We really need to make sure that the config does not load code if we don't explicitly say so. >> >> So what code was changed? Why was it loaded? >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

March 23, 2011

[Pharo-project] TFLogin Recaptcha component error

by Dario Trussardi

Hi Tony, i hope this is right reference for signal the problem. I have load the TFLogin into Pharo1.1.1. After i set the captcha key and register the TLTestApp When open in the browser the LoginTestApp the system erase the error: MessageNotUnderstood: BWRecaptchaComponent class>>ajax setRecaptchaComponent | recaptchaClass | captchaComponent := ((recaptchaClass := (Smalltalk at: #BWRecaptchaComponent ifAbsent: [ nil ])) isNil ifFalse: [ captchaComponent ifNil: [ recaptchaClass ajax ]] ifTrue: [ nil ]) I answer proced. Now the standard register option work fine and show the captcha component. When i open the AJAX rendering and do the register option the captcha component is not render. Thank, Dario

March 23, 2011

Re: [Pharo-project] Pharo 1.2 red again

by Dale Henrichs

If someone changes a configuration version directly ... instead of creating a new version, this could happen ... Dale On Mar 23, 2011, at 5:26 AM, Marcus Denker wrote: > > On Mar 23, 2011, at 12:52 PM, Torsten Bergmann wrote: > >> Pharo 1.2 is red again! >> >> DuplicatedVariableError: stylingActive is already defined in Workspace >> >> https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/195/ > > > We really need to make sure that the config does not load code if we don't explicitly say so. > > So what code was changed? Why was it loaded? > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

March 23, 2011

Re: [Pharo-project] [TODO 1.2] TODO list for releasing Pharo Full 1.2

by Miguel CobÃ¡

El miÃ©, 23-03-2011 a las 14:41 +0100, Marcus Denker escribiÃ³: > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage > > 1. 1.2 Build is broken > 2. 1.2 Config needs to load latest code from OB Repository > (or not. Maybe we should just release 1.2.1 and do that in 1.2.2) No. This is the reason the build is sometimes green some times red in hudson. The versions refered by configuration should be frozen to a given version number forever. That is, #stable, #latestVersion, #bleedingEdge and so should be banned from Pharo configurations when building a release. They are ok for end users that just want a version that works in the image they have in front of them, but not for releases, that should be repeteable! > > maybe these we push to 1.2.2: > > 3. Omnibrowser's an extra horizontal scrollbar > 4. In OB: Text in comment pane of Browser uses syntax highlighting > > 5. Update Hudson One-Click build files for 1.2 > > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

March 23, 2011

Re: [Pharo-project] Pharo 1.2 red again

by Miguel CobÃ¡

I mean, the most probable reason for this is that some configuration refers some symbolic version like #stable, #bleedingEdge and that package was updated so that there is a new #stable version whose tests aren't green in Pharo and whose previous-version tests were all green. Cheers El miÃ©, 23-03-2011 a las 13:26 +0100, Marcus Denker escribiÃ³: > On Mar 23, 2011, at 12:52 PM, Torsten Bergmann wrote: > > > Pharo 1.2 is red again! > > > > DuplicatedVariableError: stylingActive is already defined in Workspace > > > > https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/195/ > > > We really need to make sure that the config does not load code if we don't explicitly say so. > > So what code was changed? Why was it loaded? > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

March 23, 2011