From sven at stfx.eu Tue Dec 4 16:13:33 2018 From: sven at stfx.eu (Sven Van Caekenberghe) Date: Tue, 4 Dec 2018 17:13:33 +0100 Subject: [Seaside-dev] Pharo7 - git - branches - platforms - baseline ? Message-ID: <79100CAA-13F7-4830-B126-8459C95FE274@stfx.eu> Hi, Pharo 7 is coming closer to a release so it is good that Seaside loads well into the latest Pharo 7 RC, especially the #pharo7 branch. Although the differences between the #master and #pharo7 branch are small (just 2 methods), the question is how to integrate those fixes (as they are specific to pharo 7). (See the gaps in the CI build matrix). When I look at BaselineOfSeaside3 I get really confused. This is so complex, so verbose that I feel intimidated to propose any changes. Even though Seaside is complex and supports different platforms and different versions of those platforms, we should be able to do much better. What are the guidelines/ideas/plans here ? What is the strategy ? IMHO, a baseline should first and foremost clearly describe an ideal situation in #common, and only then define - ideally small - exceptions for different platforms/versions. It should be possible to first see and understand the base structure. Groups, sub components and dependencies should be clear. It might also help to cut some support for very old versions and or platforms that do not yet support git based loading. Or should each branch hold its own, much cleaner baseline ? And will we then keep on maintaining different branches ? Wasn't it also the goal to put platform differences in Grease as much as possible ? Sven From cyril.ferlicot at gmail.com Tue Dec 4 18:01:43 2018 From: cyril.ferlicot at gmail.com (Cyril Ferlicot D.) Date: Tue, 4 Dec 2018 19:01:43 +0100 Subject: [Seaside-dev] Pharo7 - git - branches - platforms - baseline ? In-Reply-To: <79100CAA-13F7-4830-B126-8459C95FE274@stfx.eu> References: <79100CAA-13F7-4830-B126-8459C95FE274@stfx.eu> Message-ID: Le 04/12/2018 à 17:13, Sven Van Caekenberghe a écrit : > Hi, > > Pharo 7 is coming closer to a release so it is good that Seaside loads well into the latest Pharo 7 RC, especially the #pharo7 branch. > > Although the differences between the #master and #pharo7 branch are small (just 2 methods), the question is how to integrate those fixes (as they are specific to pharo 7). (See the gaps in the CI build matrix). > > When I look at BaselineOfSeaside3 I get really confused. This is so complex, so verbose that I feel intimidated to propose any changes. Even though Seaside is complex and supports different platforms and different versions of those platforms, we should be able to do much better. > > What are the guidelines/ideas/plans here ? What is the strategy ? > > IMHO, a baseline should first and foremost clearly describe an ideal situation in #common, and only then define - ideally small - exceptions for different platforms/versions. It should be possible to first see and understand the base structure. > > Groups, sub components and dependencies should be clear. > > It might also help to cut some support for very old versions and or platforms that do not yet support git based loading. > > Or should each branch hold its own, much cleaner baseline ? And will we then keep on maintaining different branches ? > > Wasn't it also the goal to put platform differences in Grease as much as possible ? > Hi, I am currently cleaning a little the baseline and packages to remove everything related to Pharo < 4. One fix is already integrated. 3 other are waiting review and when they will be integrated I'll check if I can further clean it. (I think I already see one or two things I can clean but I don't want to do too many PR that will end up in conflict) As you can see here for example: https://github.com/SeasideSt/Seaside/pull/1056/files It reduce quite a lot the complexity of some parts. Another example: https://github.com/SeasideSt/Seaside/pull/1054/files > Sven > > > > _______________________________________________ > seaside-dev mailing list > seaside-dev at lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > -- Cyril Ferlicot https://ferlicot.fr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From johan at inceptive.be Tue Dec 4 19:51:59 2018 From: johan at inceptive.be (Johan Brichau) Date: Tue, 4 Dec 2018 20:51:59 +0100 Subject: [Seaside-dev] Pharo7 - git - branches - platforms - baseline ? In-Reply-To: <79100CAA-13F7-4830-B126-8459C95FE274@stfx.eu> References: <79100CAA-13F7-4830-B126-8459C95FE274@stfx.eu> Message-ID: <32A8D797-A96E-4723-8D3F-7E63E49867D8@inceptive.be> Hi Sven, > On 4 Dec 2018, at 17:13, Sven Van Caekenberghe wrote: > > Pharo 7 is coming closer to a release so it is good that Seaside loads well into the latest Pharo 7 RC, especially the #pharo7 branch. > Although the differences between the #master and #pharo7 branch are small (just 2 methods), the question is how to integrate those fixes (as they are specific to pharo 7). (See the gaps in the CI build matrix). I should delete the pharo7 branch, because all those changes were merged into develop, which is really pharo7 ready. The pharo7 branch is not. It was only created to make the changes specific to pharo7, but all changes have been merged into develop and more fixes have been made. Which gaps do you mean in the build matrix? I don’t understand. e.g. https://travis-ci.org/SeasideSt/Seaside/builds/459433036 > When I look at BaselineOfSeaside3 I get really confused. This is so complex, so verbose that I feel intimidated to propose any changes. Even though Seaside is complex and supports different platforms and different versions of those platforms, we should be able to do much better. > What are the guidelines/ideas/plans here ? What is the strategy ? The baseline is split into conceptual parts (comet, rest, core, …) I think the only one that grew out to a beast is the Pharo parts. And that part is being slimmed down (thank you Cyril) because old Pharo versions are being thrown out. I think it’s underestimated how complex a package configuration can get when you have different platforms to support. Sure, it’s possible to come in and say everything should be easier, but The only thing that, in hindsight would have been easier, is to not try to reuse packages across different Pharo versions but rather create complete copies. This is the approach we have taken for Grease. Take a look there to see what I mean. > IMHO, a baseline should first and foremost clearly describe an ideal situation in #common, and only then define - ideally small - exceptions for different platforms/versions. It should be possible to first see and understand the base structure. The differences between the platforms are not small and are hard to capture by Grease everywhere. In most cases, it is necessary to put platform-specific parts of Seaside into platform-specific packages. > Groups, sub components and dependencies should be clear. > > It might also help to cut some support for very old versions and or platforms that do not yet support git based loading. > > Or should each branch hold its own, much cleaner baseline ? And will we then keep on maintaining different branches ? We specifically merged the entire Gemstone ‘branch’ of Seaside of with the main repository because it was maintenance hell. Hence, I don’t like splitting Seaside in different platform branches. In fact, I’m certain it will fail to be maintained. We merged Gemstone back in (at ESUG in Brescia actually) and the maintenance of the entire Seaside code base has been simplified for both Pharo and Gemstone, but there is still room for improvement, obviously. Having the travis builds for all platforms is definitely a winner too. > Wasn't it also the goal to put platform differences in Grease as much as possible ? Yes it is, and we are still moving things up to Grease, but many platform differences also do not make sense to put in Grease. cheers Johan From maxleske at gmail.com Tue Dec 11 20:34:47 2018 From: maxleske at gmail.com (Max Leske) Date: Tue, 11 Dec 2018 21:34:47 +0100 Subject: [Seaside-dev] ConfigurationOfSeaside3 on develop branch In-Reply-To: <2EB3A244-E4E3-4A74-8993-AB77DBD90300@inceptive.be> References: <469640C7-DCCC-481D-ABFD-2007711C1CF6@gmail.com> <9813D090-9A36-46CA-AC60-95B3203A2A04@inceptive.be> <2EB3A244-E4E3-4A74-8993-AB77DBD90300@inceptive.be> Message-ID: On 26 Nov 2018, at 9:18, Johan Brichau wrote: > About this… > > I think the tests about the package<->grpackages stuff require the > ConfigurationOf to be present. Do you mean GRPackageTest? I couldn't find anything related to ConfigurationOf... > > Question is: do we still need those grpackages and tests? > > Cheers > Johan > >> On 24 Oct 2018, at 16:14, Johan Brichau wrote: >> >> This can be removed. >> It was there as the master copy to copy back to smalltalkhub when >> needed. >> >> Since we explicitly stop the loading from Smalltalkhub, we can throw >> it away. >> >> cheers >> Johan >> >>> On 24 Oct 2018, at 14:45, Max Leske wrote: >>> >>> Yes, I should think so. >>> >>> On 24 Oct 2018, at 13:44, Philippe Marschall wrote: >>> >>>> Hi >>>> >>>> I just noted there is a ConfigurationOfSeaside3 package on the >>>> develop >>>> branch. Am I correct to assume this can be deleted? >>>> >>>> Cheers >>>> Philippe >>>> _______________________________________________ >>>> seaside-dev mailing list >>>> seaside-dev at lists.squeakfoundation.org >>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev >>> _______________________________________________ >>> seaside-dev mailing list >>> seaside-dev at lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev >> > > _______________________________________________ > seaside-dev mailing list > seaside-dev at lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev From maxleske at gmail.com Tue Dec 11 20:35:18 2018 From: maxleske at gmail.com (Max Leske) Date: Tue, 11 Dec 2018 21:35:18 +0100 Subject: [Seaside-dev] Seaside 3.3 release sprint In-Reply-To: <78C8419E-D2B6-4570-8020-B6AB398D9FA7@inceptive.be> References: <78C8419E-D2B6-4570-8020-B6AB398D9FA7@inceptive.be> Message-ID: On 25 Nov 2018, at 17:40, Johan Brichau wrote: > Hi, > > I did a sprint this weekend to tackle several open issues for the 3.3 > release. > > All issues are closed but we still need to: > - Fix broken Squeak 5.2 (yes… see travis builds of develop branch) > - Do some manual testing (the Parasol automated tests did not yet make > it into the develop branch yet...) > - Clean up the release notes > > Anybody up to check out the Squeak issue? I'll take a look now. > > cheers > Johan > _______________________________________________ > seaside-dev mailing list > seaside-dev at lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev From maxleske at gmail.com Tue Dec 11 21:25:59 2018 From: maxleske at gmail.com (Max Leske) Date: Tue, 11 Dec 2018 22:25:59 +0100 Subject: [Seaside-dev] [squeak-dev] [Seaside] Seaside on Squeak? In-Reply-To: References: Message-ID: <77DCB526-9C92-437D-9431-6678B14539FB@gmail.com> Thanks for the hint Timothy. My suggestion is to collect all encoding names manually in Grease instead of using TextEncoder class>>allEncodingNames. Despite its name, this method only answers the "default" name of each encoding. I don't think that's the intended use case we want to support with GRGenericPharoEncoder. There, I imagine we'd like to match both 'mac-roman' and 'macroman'. Manually collecting the encoding names allows us to do that. PR: https://github.com/SeasideSt/Grease/pull/71 BTW: There should really be a message for that on TextEncoder... Cheers, Max On 8 Dec 2018, at 13:00, squeak-dev-request at lists.squeakfoundation.org wrote: > my applogies I accidentally hit send with a control key while > attempting to format the chain of reasoning. What this test does is > loop through each subclass of GRCodec and asks each one if they > support the encoding 'mac-roman' those classes are: GRNullCodec > GRPharoGenericCodec GRPharoUtf8Codec GRPharoLatin1Codec The subclasses > either hard-code their encodings in the class side > supportedEncodingNames method or they define it as a subset of > TextConverter allEncodingNames TextConverter allEncodingNames inspect > TextConverter allEncodingNames select:[:element | element asString > beginsWith:'mac'] Like GRCodec, TextConverter loops through all its > subclasses and asks them what to populate its set of names with. The > one we want is: MacRomanTextConverter encodingNames If you print that, > you see two: #('macroman' 'mac-roman') The issue, is in the > TextConverte allEncodingNames method allEncodingNames "TextConverter > allEncodingNames" | encodingNames | encodingNames := Set new. self > allSubclasses do: [:each | | names | names := each encodingNames. > names notEmpty ifTrue: [encodingNames add: names first asSymbol]]. > ^encodingNames looking at the ifTrue: block you see it only adds the > FIRST name to the set. This could be a bug in TextConverter. Since > 'mac-roman' and 'macroman' both point to the same > MacRomanTextConverter, it stands to reason that changing the test from > 'mac-roman' to 'macroman' is safe. Do that, and the test passes. > cheers, t ---- On Wed, 05 Dec 2018 08:33:02 -0500 David T. Lewis > wrote ---- Replying on the squeak-dev list to > get some more eyes on the issue. Dave On Tue, Dec 04, 2018 at > 10:17:17PM +0100, Johan Brichau wrote: > Hi, > > Two tests are > currently still failing for Squeak [1]. > - testNamedTempAt -> fails > on travis but works in an interactive image??? dunno what???s going on > but it???s an expected failure in Pharo for a long time as well??? > - > testGenericCodecMacRoman -> it seems the preferential name for the > Mac-Roman encoding became ???macroman??? in Squeak instead of > ???mac-roman???. Not sure what to think about this one??? > > Anybody > from the Squeak community who wants to step in and check on these? > > > cheers > Johan > > > [1] > https://travis-ci.org/SeasideSt/Seaside/jobs/463542906 > From maxleske at gmail.com Sat Dec 15 22:28:45 2018 From: maxleske at gmail.com (Max Leske) Date: Sat, 15 Dec 2018 23:28:45 +0100 Subject: [Seaside-dev] Load failure of Seaside3 into Squeak 5.2alpha In-Reply-To: References: <1F06DB86-CC5A-4056-A902-AF330ED7476B@rowledge.org> <0C328C19-DB83-42E3-9366-9EAF7DF0D896@gmail.com> <3F51CF57-3007-4479-BCED-4C1ABA437205@gmail.com> <96DE1CA9-54BF-4462-8D5D-53095B22C3D2@rowledge.org> <1786B1A8-41F3-492A-BB7B-2AC1385DAE0E@gmail.com> Message-ID: <79BAF68D-1A19-4D53-84D0-95554170AD20@gmail.com> Hi Tim, Thanks again for you help. On 12 Nov 2018, at 2:31, tim Rowledge wrote: >> On 2018-11-11, at 6:30 AM, Max Leske wrote: >> >> Hi Tim, Tobias, >> >> I've let this issue lie around after the change to Squeak website and >> I'm not entirely sure if I need to do anything more. Tim, is this >> still an open issue for you? > > I've run test loads just to see how it works for me now. Again, Squeak > 5.2, RaspberryPi. > > SqueakMap - dead easy; update the list of course. Pick Seaside. Click > install. > I see it was even updated yesterday. Starts loading metacello etc. > Loads Seaside. No problems. Web browser connects immediately. A+++ > would install again. > > Github, as pointed to by the https://squeak.org/projects/ page, where > it points on to https://github.com/SeasideSt/Seaside page, where it > points to https://github.com/dalehenrich/metacello-work, which points > to https://github.com/dalehenrich/metacello-work where finally it > tells me to 'Installer ensureRecentMetacello.' > Ok, that starts metacello loading. Wait a while. Oh, yes, go back to > the github page for Seaside, copy & paste > 'Metacello new > baseline:'Seaside3'; > repository: 'github://SeasideSt/Seaside:master/repository'; > load' > Seaside control panel is *not* helpfully initialised and the only > 'adaptor' offered (a WATestServerAdaptor) does not appear to allow a > browser to connect. The SqueakMap install provides a helpfully usable > WAWebServerAdaptor. > C - would like to whine at vendor about delivery options. I've improved the loading instructions for Squeak and opened an issue for control panel initialisation and adaptor installation: https://github.com/SeasideSt/Seaside/issues/1074. > > 'Quick Install' as pointed to by the https://squeak.org/projects/ > page - where one is advised to use the same metacello incantation as > above, but not given the nice simple 'Installer > ensureRecentMetacello.' advise. In fact the metacello quick install on > the same page is quite different, a bit confusing and possibly now out > of date. Further, the project page is, as mentioned above, pointing to > the wrong github and potentially worse, it is anchored such that you > won't see the advice to jump to the current github page unless you > scroll around. > D - offputting confusion and possible incorrect code loaded by > following advice. Complain to credit card company and demand refund. I've created a pull request for squeak.org with improvements: https://github.com/squeak-smalltalk/squeak.org/pull/26. Cheers, Max > > Looks like some improved stuff in the project & quick install texts > are needed, probably something improved in the githup load script, and > correcting of the links to the metacello github stuff. But the SM part > is just clickalicious! > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > My computer NEVER cras > > > _______________________________________________ > seaside-dev mailing list > seaside-dev at lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev From maxleske at gmail.com Sun Dec 16 17:14:47 2018 From: maxleske at gmail.com (Max Leske) Date: Sun, 16 Dec 2018 18:14:47 +0100 Subject: [Seaside-dev] Wrong method source pointer in Squeak5.2 Message-ID: Hi, We have an issue in Seaside where a loaded test method holds a bad source pointer. We only noticed because this method accesses the debugger map. How to reproduce: 1. clone SmalltalkCI: git clone git at github.com:hpi-swa/smalltalkCI.git 2. clone Seaside: git clone git at github.com:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79 3. install Seaside in Squeak5.2: /run.sh --headful -s Squeak-5.2 /.smalltalk.ston 4. Run the test WAPharoDebuggerTest>>testNamedTempAt and you'll see a debugger pop up for an UndeclaredVariable. The source lookup is performed in the changes file but in the middle of a chunk of binary (font) data. I can can only speculate that some of that binary data introduces random chunks which messes with the offsets. We're adding a workaround for that particular test for now. Let me know if I can help track down the issue. Cheers, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: