seaside-dev December 2018

seaside-dev@lists.squeakfoundation.org

4 participants
6 discussions

Wrong method source pointer in Squeak5.2
by Max Leske 16 Dec '18

16 Dec '18

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@github.com:hpi-swa/smalltalkCI.git 2. clone Seaside: git clone git@github.com:SeasideSt/Seaside.git; git checkout 9cb54a7b14cd254ef318294905c4e8dda8dd9f79 3. install Seaside in Squeak5.2: <path to SmalltalkCI>/run.sh --headful -s Squeak-5.2 <path to Seaside>/.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

1 0

Load failure of Seaside3 into Squeak 5.2alpha
by tim Rowledge 15 Dec '18

15 Dec '18

Just tried loading seaside into the current near-release squeak 5.2. It failed. The problem occurs in MetacelloVersionConstructor>>#calculate:project: because the symbolicVersionMap dictionary looks like this - a Dictionary(#bleedingEdge->'1.3.0-baseline' #development->'1.3.0-baseline' #'release1.0'->'1.0.12' #'release1.1'->'1.1.13.1' #'release1.2'->'1.2.7' #'release1.3'->'1.3.0' #stable->#release1 ) When doing the little dance near the end of the method we have block params 'symbolic' = #stable & 'original' = #release1 but then try to look up #release1 only to find it isn't there. I'm guessing that it should actually be #'release1.0', which would then find '1.0.12'. But I really don't think I ought to mess a lot with this bit of code, since I've never had anything to do with mc development before. Best not to break everything for everyone... In the debugger I risked 'fixing' the dictionary and seeing if things might proceed happily. It went on for a while and stopped during 'Loading Seaside-CoreJohanBrichau.875' because #greaseInteger is not implemented for Character. It is installed for Integer, Number and String, though the last would of course fail due to no Character implementation. So I added a wild guess of '^self asInteger' and proceeded. This got me as far as initializing WAKeyGenerator class a bit later in the same package. This failed because a) GRPlatform had not been initialized and thus returned nil for #current, which meant dNU: #newRandom was inevitable b) Looks like there is no platform subclass to even make the following #newRandom work. So there I am stuck. Current googling is not showing me anything that appears to explain the apparently missing class(es) etc. Pointers? tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Strange OpCodes: PNG: Pass Noxious Gas

4 13

Re: [Seaside-dev] [squeak-dev] [Seaside] Seaside on Squeak?
by Max Leske 11 Dec '18

11 Dec '18

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(a)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 > <lewis(a)mail.msen.com> 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 >

1 0

Seaside 3.3 release sprint
by Johan Brichau 11 Dec '18

11 Dec '18

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? cheers Johan

2 1

ConfigurationOfSeaside3 on develop branch
by Philippe Marschall 11 Dec '18

11 Dec '18

Hi I just noted there is a ConfigurationOfSeaside3 package on the develop branch. Am I correct to assume this can be deleted? Cheers Philippe

3 4

Pharo7 - git - branches - platforms - baseline ?
by Sven Van Caekenberghe 04 Dec '18

04 Dec '18

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

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev December 2018