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

Re: [Pharo-project] [Hudson] Jenkins

by Marcus Denker

>> > > There is one *generic* Jenkins for all of INRIA. (a template: request a CI server --> a CI server > is set up. Automatically, configured to look into LDAP for account data, for example). > Maybe to explain it better: We have *no* shell access to the server that the frontend is running on. So replacing files in the hudson installation is not possible. If there is a plugin for changing the logo, we can use that. If it means relacing files on disk, we can not do that. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 22, 2011

Re: [Pharo-project] [Hudson] Jenkins

by Geert Claes

Marcus Denker-4 wrote: > > And really: Is this important enough to even discuss it? > Of course it is not :) -- View this message in context: http://forum.world.st/Hudson-Jenkins-tp3538245p3541756.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 22, 2011

Re: [Pharo-project] [Hudson] Jenkins

by Marcus Denker

On May 22, 2011, at 10:46 AM, Geert Claes wrote: > > Marcus Denker-4 wrote: >> >> Yes, the IT services provide infrastructure that creates Jenkins setups. >> E.g. we can >> request one for RMOD, and there will be one for Rmod. >> >> Yes, we could request them to extend this meta-setup it with changing the >> look. But the thing is that >> this *We* can not do, but the admines would need to do it. And it would be >> work to provide >> a UI for uploading images, checking they are good... >> > > Provide a UI for uploading images? Say what? > There is one *generic* Jenkins for all of INRIA. (a template: request a CI server --> a CI server is set up. Automatically, configured to look into LDAP for account data, for example). This is why it took a while to move to Jenkins from Hudson. Remember, INRIA is not just RMod. To put into that the possibility of changing the look means to provide a *generic* way that everyone can modify the look. Whithout manual intervention. This is *work* and this is *not important*. This combination makes it very unlikely to happen anytime soon. And really: Is this important enough to even discuss it? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 22, 2011

Re: [Pharo-project] [Hudson] Jenkins

by Geert Claes

Marcus Denker-4 wrote: > > Yes, the IT services provide infrastructure that creates Jenkins setups. > E.g. we can > request one for RMOD, and there will be one for Rmod. > > Yes, we could request them to extend this meta-setup it with changing the > look. But the thing is that > this *We* can not do, but the admines would need to do it. And it would be > work to provide > a UI for uploading images, checking they are good... > Provide a UI for uploading images? Say what? Marcus Denker-4 wrote: > > And my feeling is that they have other things that are more important to > do (the whole > setup is in test mode...) > > Especially we should *use* it before running back and requesting even more > changes. > (and unimportant ones, especially)... > > It's just not a good idea to do that now. > > Marcus > Look-and-feel has historically always come in second (except at companies like Apple, even when they were a small) and developers have always defended the *use* first before *look-n-feel* ... I reckon its bs! The 3 images attached are exactly the same size and even have the same name for crying out loud. How hard is it really to replace 3 resource images? Anyhow, it was just a suggestion do with them what you want :) -- View this message in context: http://forum.world.st/Hudson-Jenkins-tp3538245p3541725.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 22, 2011

Re: [Pharo-project] [Hudson] Jenkins

by Marcus Denker

On May 22, 2011, at 8:55 AM, Geert Claes wrote: > > Marcus Denker-4 wrote: >> >> The problem is that this is a company wide installation serving many >> projects... >> Pharo is just one of them. >> > > But everything is Pharo based and even the URL includes "Pharo" does it not? > Yes, the IT services provide infrastructure that creates Jenkins setups. E.g. we can request one for RMOD, and there will be one for Rmod. Yes, we could request them to extend this meta-setup it with changing the look. But the thing is that this *We* can not do, but the admines would need to do it. And it would be work to provide a UI for uploading images, checking they are good... And my feeling is that they have other things that are more important to do (the whole setup is in test mode...) Especially we should *use* it before running back and requesting even more changes. (and unimportant ones, especially)... It's just not a good idea to do that now. Marcus > -- > View this message in context: http://forum.world.st/Hudson-Jenkins-tp3538245p3541662.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 22, 2011

Re: [Pharo-project] [Hudson] Jenkins

by Geert Claes

Marcus Denker-4 wrote: > > The problem is that this is a company wide installation serving many > projects... > Pharo is just one of them. > But everything is Pharo based and even the URL includes "Pharo" does it not? -- View this message in context: http://forum.world.st/Hudson-Jenkins-tp3538245p3541662.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 22, 2011

Re: [Pharo-project] [Hudson] Jenkins

by Marcus Denker

On May 21, 2011, at 7:54 PM, Geert Claes wrote: > Hi Marcus, Maybe you could replace the resource images with the attached > images - replaced "Jenkins" with "Pharo" :) > The problem is that this is a company wide installation serving many projects... Pharo is just one of them. > Re-branding: > > http://forum.world.st/file/n3540934/title.png title.png > http://forum.world.st/file/n3540934/jenkins.png jenkins.png > http://forum.world.st/file/n3540934/topbar.png topbar.png > > -- > View this message in context: http://forum.world.st/Hudson-Jenkins-tp3538245p3540934.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 22, 2011

Re: [Pharo-project] ChangeSet changedMessageList broken

by Benjamin

On May 22, 2011, at 2:29 AM, Stefan Marr wrote: > Hi: > > On 22 May 2011, at 01:56, Benjamin wrote: > >> The "problem" is that MethodReference were used either it was for a method or for a comment. And in this case, the selector was set to #Comment . >> Now, there is SourcedMethodReference for methods, and CommentReference for comments. >> >> So this example should be changed I guess. > > > So, the proper implementation would be the following? (now uses CommentReference) > > changedMessageList > "Used by a message set browser to access the list view information." > > | messageList | > messageList := OrderedCollection new. > changeRecords associationsDo: [:clAssoc | | classNameInParts classNameInFull | > classNameInFull := clAssoc key asString. > classNameInParts := classNameInFull findTokens: ' '. > > (clAssoc value allChangeTypes includes: #comment) ifTrue: > [messageList add: > (CommentReference class: (Smalltalk globals classNamed: classNameInParts first))]. > > clAssoc value methodChangeTypes associationsDo: [:mAssoc | > (#(remove addedThenRemoved) includes: mAssoc value) ifFalse: > [messageList add: > (SourcedMethodReference new > setClassSymbol: classNameInParts first asSymbol > classIsMeta: classNameInParts size > 1 > methodSymbol: mAssoc key > stringVersion: classNameInFull, ' ' , mAssoc key)]]]. > ^ messageList asArray sort > > > > Well well, thats not really nice. CommentReference is not entirely polymorphic to MethodReference. > > It should have > CommentReference>>#category > ^ self actualClass category > So let's add it ^^ Ben > to be able to move #topLevelPackageName from MethodReference to SourceReference. Every piece of source is part of some package, no? Including the class comments. Well, at least it breaks our file-out mechanism if that is not true. > > Best regards > Stefan > >> >> >> >> Ben >> >> >> On May 21, 2011, at 11:41 PM, Stefan Marr wrote: >> >>> Hello: >>> >>> The following example is broken: >>> >>> ChangeSet new commentClass: ChangeSet; changedMessageList >>> >>> It will raise an exception that no #Comment message was found in the ChangeSet class. >>> (BTW: the key not found error does not name the key, which is rather inconvenient) >>> >>> The reason seems to be a change in ChangeSet>>#changedMessageList. >>> >>> The change is tracked as being done by Benjamin Van Ryseghem (11/6/2010 22:11) >>> and seems to switch from MethodReference to SourcedMethodReference, which breaks the example. >>> >>> Does anyone know the intention or context of this change? >>> Is it possible to revert to Marcus' pervious version of that method? >>> >>> A test for this bug could be the lines of: >>> >>> >>> >>> testChangedMessageListAndComments >>> | changeSet | >>> changeSet := ChangeSet new. >>> changeSet commentClass: ChangeSet. >>> self assert: 1 equals: changeSet changedMessageList size. >>> self assert: ((changeSet at: 1) isKindOf: MethodReference). >>> self assert: #Comment equals: (changeSet at: 1) methodSymbol. >>> >>> Best regards >>> Stefan >>> >>> -- >>> Stefan Marr >>> Software Languages Lab >>> Vrije Universiteit Brussel >>> Pleinlaan 2 / B-1050 Brussels / Belgium >>> http://soft.vub.ac.be/~smarr >>> Phone: +32 2 629 2974 >>> Fax: +32 2 629 3525 >>> >>> >> >> > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

May 22, 2011

Re: [Pharo-project] ChangeSet changedMessageList broken

by Stefan Marr

Hi: On 22 May 2011, at 01:56, Benjamin wrote: > The "problem" is that MethodReference were used either it was for a method or for a comment. And in this case, the selector was set to #Comment . > Now, there is SourcedMethodReference for methods, and CommentReference for comments. > > So this example should be changed I guess. So, the proper implementation would be the following? (now uses CommentReference) changedMessageList "Used by a message set browser to access the list view information." | messageList | messageList := OrderedCollection new. changeRecords associationsDo: [:clAssoc | | classNameInParts classNameInFull | classNameInFull := clAssoc key asString. classNameInParts := classNameInFull findTokens: ' '. (clAssoc value allChangeTypes includes: #comment) ifTrue: [messageList add: (CommentReference class: (Smalltalk globals classNamed: classNameInParts first))]. clAssoc value methodChangeTypes associationsDo: [:mAssoc | (#(remove addedThenRemoved) includes: mAssoc value) ifFalse: [messageList add: (SourcedMethodReference new setClassSymbol: classNameInParts first asSymbol classIsMeta: classNameInParts size > 1 methodSymbol: mAssoc key stringVersion: classNameInFull, ' ' , mAssoc key)]]]. ^ messageList asArray sort Well well, thats not really nice. CommentReference is not entirely polymorphic to MethodReference. It should have CommentReference>>#category ^ self actualClass category to be able to move #topLevelPackageName from MethodReference to SourceReference. Every piece of source is part of some package, no? Including the class comments. Well, at least it breaks our file-out mechanism if that is not true. Best regards Stefan > > > > Ben > > > On May 21, 2011, at 11:41 PM, Stefan Marr wrote: > >> Hello: >> >> The following example is broken: >> >> ChangeSet new commentClass: ChangeSet; changedMessageList >> >> It will raise an exception that no #Comment message was found in the ChangeSet class. >> (BTW: the key not found error does not name the key, which is rather inconvenient) >> >> The reason seems to be a change in ChangeSet>>#changedMessageList. >> >> The change is tracked as being done by Benjamin Van Ryseghem (11/6/2010 22:11) >> and seems to switch from MethodReference to SourcedMethodReference, which breaks the example. >> >> Does anyone know the intention or context of this change? >> Is it possible to revert to Marcus' pervious version of that method? >> >> A test for this bug could be the lines of: >> >> >> >> testChangedMessageListAndComments >> | changeSet | >> changeSet := ChangeSet new. >> changeSet commentClass: ChangeSet. >> self assert: 1 equals: changeSet changedMessageList size. >> self assert: ((changeSet at: 1) isKindOf: MethodReference). >> self assert: #Comment equals: (changeSet at: 1) methodSymbol. >> >> Best regards >> Stefan >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 22, 2011

Re: [Pharo-project] ChangeSet changedMessageList broken

by Benjamin

The "problem" is that MethodReference were used either it was for a method or for a comment. And in this case, the selector was set to #Comment . Now, there is SourcedMethodReference for methods, and CommentReference for comments. So this example should be changed I guess Ben On May 21, 2011, at 11:41 PM, Stefan Marr wrote: > Hello: > > The following example is broken: > > ChangeSet new commentClass: ChangeSet; changedMessageList > > It will raise an exception that no #Comment message was found in the ChangeSet class. > (BTW: the key not found error does not name the key, which is rather inconvenient) > > The reason seems to be a change in ChangeSet>>#changedMessageList. > > The change is tracked as being done by Benjamin Van Ryseghem (11/6/2010 22:11) > and seems to switch from MethodReference to SourcedMethodReference, which breaks the example. > > Does anyone know the intention or context of this change? > Is it possible to revert to Marcus' pervious version of that method? > > A test for this bug could be the lines of: > > > > testChangedMessageListAndComments > | changeSet | > changeSet := ChangeSet new. > changeSet commentClass: ChangeSet. > self assert: 1 equals: changeSet changedMessageList size. > self assert: ((changeSet at: 1) isKindOf: MethodReference). > self assert: #Comment equals: (changeSet at: 1) methodSymbol. > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

May 21, 2011