Hi, So we did -> an update 30837 to remove a bit of Scriploader methods so the do not end up in the .sources file (60.000 LOCâ¦) -> then we condensed the sources and changes and re-uploaded that file. -> Zeroconf has been updated. Now it download V1, V2 and V3 sources⦠(which is far from nice⦠but works). -> the sources files is here: http://files.pharo.org/sources/ Overall, the whole sources and changes mechanism again showed that it was not designed with the idea in mind to be able to ârelease at any pointâ. Our goal has to be that the build server artefact is the release artefact. Concerning .sources and .changes this is not the case⦠we really need another design. Next -> update to fix the direct pointer to the PharoV2 sources in the source downloader -> MC history pruning Marcus
On 28 Apr 2014, at 15:34, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
So we did
-> an update 30837 to remove a bit of Scriploader methods so the do not end up in the .sources file (60.000 LOCâ¦) -> then we condensed the sources and changes and re-uploaded that file. -> Zeroconf has been updated. Now it download V1, V2 and V3 sources⦠(which is far from nice⦠but works). -> the sources files is here: http://files.pharo.org/sources/
Overall, the whole sources and changes mechanism again showed that it was not designed with the idea in mind to be able to ârelease at any pointâ. Our goal has to be that the build server artefact is the release artefact. Concerning .sources and .changes this is not the case⦠we really need another design.
e.g. now we have three tests failing:
SlotTests.SlotTraitsTest.testClassWithTrait2 Tests.Files.SourceFileArrayTest.testProtocol Tests.Files.SourceFileArrayTest.testTimeStamp
I think the first goal of Pharo4 should be to make the artefact from the build server a true release artefact⦠Marcus
On 28 Apr 2014, at 15:58, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Apr 2014, at 15:34, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
So we did
-> an update 30837 to remove a bit of Scriploader methods so the do not end up in the .sources file (60.000 LOCâ¦) -> then we condensed the sources and changes and re-uploaded that file. -> Zeroconf has been updated. Now it download V1, V2 and V3 sources⦠(which is far from nice⦠but works). -> the sources files is here: http://files.pharo.org/sources/
Overall, the whole sources and changes mechanism again showed that it was not designed with the idea in mind to be able to ârelease at any pointâ. Our goal has to be that the build server artefact is the release artefact. Concerning .sources and .changes this is not the case⦠we really need another design.
e.g. now we have three tests failing:
SlotTests.SlotTraitsTest.testClassWithTrait2 Tests.Files.SourceFileArrayTest.testProtocol Tests.Files.SourceFileArrayTest.testTimeStamp
I think the first goal of Pharo4 should be to make the artefact from the build server a true release artefactâ¦
A close examination shows that *all* class side Traits methods have broken source pointers⦠So letâs revert everything⦠(and I guess we do not need any other proof that *THE BUILD SERVER ARTEFACT NEEDS TO BE THE ARTEFACT OF RELEASE*. Marcus.
On 28 Apr 2014, at 16:21, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 28 Apr 2014, at 16:12, Marcus Denker <marcus.denker@inria.fr> wrote:
A close examination shows that *all* class side Traits methods have broken source pointersâ¦
Maybe that is just an oversight and easily fixed ?
I reverted⦠the condenser needs to be fixed and after we should waste another hours on doing all this again. Marcus
On 28 Apr 2014, at 15:58, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Apr 2014, at 15:34, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
So we did
-> an update 30837 to remove a bit of Scriploader methods so the do not end up in the .sources file (60.000 LOCâ¦) -> then we condensed the sources and changes and re-uploaded that file. -> Zeroconf has been updated. Now it download V1, V2 and V3 sources⦠(which is far from nice⦠but works). -> the sources files is here: http://files.pharo.org/sources/
Overall, the whole sources and changes mechanism again showed that it was not designed with the idea in mind to be able to ârelease at any pointâ. Our goal has to be that the build server artefact is the release artefact. Concerning .sources and .changes this is not the case⦠we really need another design.
e.g. now we have three tests failing:
SlotTests.SlotTraitsTest.testClassWithTrait2
Tests.Files.SourceFileArrayTest.testProtocol
It seems that there is a minor difference in the method timestamp: testProtocol "Test that we can access protocol correctly" "self debug: #testProtocol" | okCm notOkCm | okCm := Point>>#dist: . self assert: (SourceFiles sourcedDataAt: okCm sourcePointer) = 'Point methodsFor: ''point functions'' stamp: ''lr 7/4/2009 10:42'''. while SourceFiles sourcedDataAt: okCm sourcePointer equals 'Point methodsFor: ''point functions'' stamp: ''lr 7/4/2009 10:42'' prior: 0' it is just the prior: 0
Tests.Files.SourceFileArrayTest.testTimeStamp
same here, the rest is OK
I think the first goal of Pharo4 should be to make the artefact from the build server a true release artefactâ¦
Marcus
participants (2)
-
Marcus Denker -
Sven Van Caekenberghe