Squeak-dev December 2019

squeak-dev@lists.squeakfoundation.org

32 participants
256 discussions

The Trunk: Graphics-mt.406.mcz
by commits＠source.squeak.org 06 Jan '20

06 Jan '20

Marcel Taeumel uploaded a new version of Graphics to project The Trunk: http://source.squeak.org/trunk/Graphics-mt.406.mcz ==================== Summary ==================== Name: Graphics-mt.406 Author: mt Time: 17 January 2019, 11:18:39.003727 am UUID: 027d00a7-113d-4b9f-aaec-79e3373339c1 Ancestors: Graphics-mt.405 Adds an informative string representation for LayoutFrame to support layout design and debugging. =============== Diff against Graphics-mt.405 =============== Item was added: + ----- Method: LayoutFrame>>printOn: (in category 'printing') ----- + printOn: aStream + + super printOn: aStream. + + aStream nextPutAll: '( '. + + { {'l'. self leftFraction. self leftOffset}. {'t'. self topFraction. self topOffset}. {'r'. self rightFraction. self rightOffset}. {'b'. self bottomFraction. self bottomOffset} } do: [:spec | + aStream nextPutAll: spec first; space. + + spec second printOn: aStream maxDecimalPlaces: 2. + + aStream nextPutAll: ((spec third ifNil: [0]) >= 0 ifTrue: ['+'] ifFalse: ['-']). + (spec third ifNil: [0]) abs printOn: aStream maxDecimalPlaces: 0] + separatedBy: [aStream space]. + + aStream nextPutAll: ' )'.!

3 2

Obsolete classes
by Nicolas Cellier 06 Jan '20

06 Jan '20

Hi all, I noticed two obsolete classes related to Preferences. They disappear if evaluating: PreferenceViewRegistry removeObsolete. I did not see that in ReleaseBuilder, is it missing? Or should we just put that in package postscript?

3 2

The Inbox: ToolBuilder-Kernel-tpr.135.mcz
by commits＠source.squeak.org 06 Jan '20

06 Jan '20

A new version of ToolBuilder-Kernel was added to project The Inbox: http://source.squeak.org/inbox/ToolBuilder-Kernel-tpr.135.mcz ==================== Summary ==================== Name: ToolBuilder-Kernel-tpr.135 Author: tpr Time: 31 December 2019, 1:38:05.296265 pm UUID: 85fb4bde-73a1-4dde-b7c2-bec1821f90eb Ancestors: ToolBuilder-Kernel-mt.134 change the default position for progress bars to slightly below the center of the screen. This should at least help with cases where a notifier/conformer/informer pops up during a large package load and gets hidden behind the progress bar morph. The Rectangle method should probably be moved back to Graphics-Primitives but by including it here we can avoid the potential for a dNU whilst loading this. =============== Diff against ToolBuilder-Kernel-mt.134 =============== Item was changed: ----- Method: ProgressInitiationException class>>preferredProgressBarPosition (in category 'accessing') ----- preferredProgressBarPosition + ^ PreferredProgressBarPosition ifNil: [ #belowCenter ]! - ^ PreferredProgressBarPosition ifNil: [ #center ]! Item was added: + ----- Method: Rectangle>>belowCenter (in category '*ToolBuilder-Kernel-accessing') ----- + belowCenter + "Answer the point slightly below the center of the receiver. This is a good candidate spot for progress morphs to default to since it leaves room to see any other dialogues that default to screen center" + + ^self topLeft + self bottomRight // (2(a)1.7)!

2 1

The Inbox: Morphic-tpr.1616.mcz
by commits＠source.squeak.org 06 Jan '20

06 Jan '20

A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-tpr.1616.mcz ==================== Summary ==================== Name: Morphic-tpr.1616 Author: tpr Time: 31 December 2019, 1:43:56.638985 pm UUID: 4b649df1-02a9-4b01-a27b-da8e9a9b543a Ancestors: Morphic-nice.1615 prevent the requested position from chaging if the progress bar is already open and in use; this should stop it leapingabout the screen like someone being pursued by angry Bees =============== Diff against Morphic-nice.1615 =============== Item was changed: ----- Method: SystemProgressMorph>>requestedPosition: (in category 'accessing') ----- requestedPosition: anObject + "only change the progress bar position if this is an occasion when the progress bar is opening with a single active bar. After that we don't want to change the position and leap around the screen" + activeSlots < 1 ifTrue:[ requestedPosition := anObject]! - - requestedPosition := anObject!

2 1

Do I really have to configure the inbox repository for each single package?
by Thiede, Christoph 06 Jan '20

06 Jan '20

Hi all, in the meantime, I probably have a really boring question for you: Is there any way to configure the inbox repo once for all Squeak packages? (Of course, there is a way, but I can't find it.) I am strictly following the instructions from the wiki<https://wiki.squeak.org/squeak/6545> to create the repository, but it does not appear for any trunk package: [cid:dd02894b-b726-43d1-a6b6-9815c3e0dc19] (no package selected) [cid:e30f6a1d-ff79-4f7b-ae0c-5c539bc8ba57] (MorphicTests selected) I admit that in all the time, I was too lazy to ask this questions so I added the repository again and again, for each single package I needed ... This probably isn't the right way to do it, is it? How can I enter the inbox repo code once for all packages? Thanks in advance, Christoph

6 11

The Inbox: Tools-jr.929.mcz
by commits＠source.squeak.org 03 Jan '20

03 Jan '20

A new version of Tools was added to project The Inbox: http://source.squeak.org/inbox/Tools-jr.929.mcz ==================== Summary ==================== Name: Tools-jr.929 Author: jr Time: 30 December 2019, 3:20:08.513977 pm UUID: 0a4d62fd-022e-1844-b6bc-db1502ab2466 Ancestors: Tools-cmm.928 Show browsed environment in Browser title if it is not the default environment. =============== Diff against Tools-cmm.928 =============== Item was changed: ----- Method: Browser>>defaultBrowserTitle (in category 'initialize-release') ----- defaultBrowserTitle + | title | + title := 'System Browser'. + ^ environment = self class environment + ifTrue: [title] + ifFalse: [title, ' on environment ', environment asString]! - ^ 'System Browser'!

5 7

Unmerged trunk versions
by Jakob Reschke 01 Jan '20

01 Jan '20

Hi, I just noticed that Tools-ct.915 is in Trunk, but not part of the ancestry of the latest version: [image: image.png] Might want to double-check such things before the release. Kind regards, Jakob

4 5

Bouncing progress bars and hiding of notifiers
by tim Rowledge 01 Jan '20

01 Jan '20

Something annoying and hopefully simple to fix in a way that makes it worth getting into 5.3 is the way progress bars can bounce around the screen. It's visually distracting and somehow a bit tacky. It's not the particular location of the morph (more on that later) but the bounce of the dratt ed thing. I *think* that the simplest way to solve this is to prevent a new #requestedPosition: from being noted when the progress bar is already in operation. The obvious way to do this might be to only set the requestedPosition if it is currently nil. However, having a persistent class var UniqueInstance complicates life a fraction since we can't rely on the requested position being nil when we 'first' open a progress bar. We could probably set it back to nil in SystemProgressMorph>>#freeSlot: when the 'self delete' is run. For a simplest-possible fix, it looks like checking the activeSlots value is effective; by not changing the requested position if activeSlots > 0 it seems to work. My example here is 'Progress' displayProgressAt: Display center from: 0 to: 10 during: [:bar | 0 to: 10 do: [:i | bar value: i. 'Progress2' displayProgressAt: 200@300 from: 0 to: 100 during: [:baz | 0 to: 100 do: [:j | baz value: j. (Delay forMilliseconds: 2) wait]]]]. ... where previously the progress bar would leap tall buildings in a single bound. You get the picture. Proposed fix in inbox Morphic-tpr.1616 A related issue we have discussed on the list before is the unfortunate case where sometihng goes wrong during a large upload and a Notifier/Informer/Confirmer gets hidden behind a progress bar with many active bars. I've seen this during loading large packages like Seaside, for example. The system is stuck waiting for you to do something with the notifier but it is sat behind a large progress bar and nobody has a clue what is happening. A very simple workaround for this is to slightly offset the default position used when no explicit position is provided for the progress bar. Currently that is #center, as in centre of the screen. I noticed we already have a related solution in Rectangle - #aboveCenter as used in ModalSystemWindowView. So by adding a #belowCenter that aims a bit below the center (duh) we get a progress bar defaulting to just a bit lower on the screen. Obviously this doesn't solve for any cases where the bar is deliberately opened at the screen center. I'd like to suggest setting the default position for the assorted notifier/confirmer/informer windows using the #aboveCenter but right now as I look at the code for opening assorted UserDialogBoxMorphs I find my brain melting. Some methods accept an argument for the position but ignore it, some test the position for nil and use a preferred position, some use the current Hand position in combination with the center point of a specified submorph... crikey. I suspect there are better ways to solve the problem. Perhaps making sure the progress bar doesn't end up in front might be simpler? Perhaps catching the inform/confirm request and incorporating it into any active progress bar morph; that seems more complex than we'd want now. Proposed improvement in inbox ToolBuilder-Kernel-tpr.135 tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim BASIC is to computer programming as QWERTY is to typing.

3 2

[BUG] Cannot compile cascade sent to block
by Thiede, Christoph 01 Jan '20

01 Jan '20

Hi all! :-) Steps to reproduce: Do it: [true] whileTrue; whileFalse Expected behavior: The script is compiled and executed (and an infinite loop occurs). Actual behavior: [cid:60074202-9794-48ae-a5fd-57507c88211b] Further investigations: In #analyseTempsWithin:rootNode:assignmentPools:, the inner BlockNode [true] is not computed a blockExtent, because it is optimized. This leads to a nil key in the ByteCodeEncoder's blockExtentsToLocals. A fast solution would be to skip nil blockExtents in #noteBlockExtent:hasLocals:, but that's a dirty workaround. Similar bug: Try to do: Object newSubclass compile: 'iWontCompile: foo foo. [true] whileTrue; whileFalse' Fails with: [cid:8ddf552d-c1a1-4498-9284-472389ef8208] Again, the problem is that blockExtent isNil. Workaround: Send #yourself to the block before sending the cascade. This prevents the receiver from being optimized. Please note that this problem does not only occur in case of special blocks. For example, [Sensor anyButtonPressed] whileTrue; whileFalse fails as well. How to fix this appropriately? I'm not sure whether I understand the whole idea of blockExtent so far. According to the documentation comment, it should be okay to be nil; however, the #blockExtent comment does not mention this fact. Please see the attached changeset for an approach to fix the issue. All tests from KernelTests-Methods and most tests from Test-Compiler pass it, except of the testAllNodePCs* which time out in my fresh image. It would be great to hear if this is the right way to solve the bug, or just extending a workaround :-) Best, Christoph

5 17

Unknown cookie field: SameSite
by John-Reed Maffeo 01 Jan '20

01 Jan '20

This message is showing up in Transcript. It originates in #WebCookie readFrom: . I tried to add sameSite to the method, but my naive attempt did not work. I also added getter and setter for the new cookie. It originates from a device called HDHomeRun CONNECT on my local network which I access via HTTP. There is some information available <https://web.dev/samesite-cookies-explained/> that describes it. The incoming text appears to be '__cfduid=de417e50c7d97807e66b4a536a928eade1577808700; expires=Thu, 30-Jan-20 16:11:40 GMT; path=/; domain=.hdhomerun.com; HttpOnly; SameSite=Lax' 'From Squeak5.2 of 13 December 2018 [latest update: #18229] on 31 December 2019 at 9:18:36 am'! !WebCookie methodsFor: 'initialize' stamp: 'jrm 12/31/2019 09:18'! readFrom: aStream "Read a cookie from the given stream" | keyval key val | aStream skipSeparators. self halt. name := (aStream upTo: $=) withBlanksTrimmed. value := (aStream upTo: $;) withBlanksTrimmed. [aStream atEnd] whileFalse:[ keyval := aStream upTo: $;. key := (keyval copyUpTo: $=) withBlanksTrimmed. val := (keyval copyAfter: $=) withBlanksTrimmed. key asLowercase caseOf: { ['expires'] -> [self expiry: (self readExpiryFrom: val)]. ['path'] -> [self path: (WebUtils unquote: val)]. ['domain'] -> [self domain: (WebUtils unquote: val)]. ['secure'] -> [self secure: true]. ['version'] -> [self version: val]. ['httponly'] -> [self httpOnly: true]. ['comment'] ->[self comment: val]. ['max-age'] ->[self expirySeconds: val asNumber]. ['SameSite'] -> [self sameSite: val]. } otherwise:[Transcript show: 'Unknown cookie field: ', key]. ].! ! any suggestions? -- John-Reed Maffeo

2 2

← Newer
1
...
4
5
6
7
8
9
10
...
26
Older →

Jump to page: