Squeak-dev October 2018

squeak-dev@lists.squeakfoundation.org

41 participants
130 discussions

Smalltalk Software House
by Keith 20 Oct '18

20 Oct '18

Dear All, I am trying to deliver myself from the fate of having to seek gainful employment working with PHP/Javascript. I am wondering if anyone would be interested in joining forces to create a virtual Smalltalk software house. I am somewhat surprised to find that React/Javascript appears to be occupying the very same cross platform non-native UI space that Squeak has had for so many years without making a significant impression. I do wonder whether the fact that Oracle are charging for Java 11, and the potential of web assembly might give smalltalk a new lease of life. ideas thoughts? Keith

2 1

The Inbox: Chronology-Core-cmm.13.mcz
by commits＠source.squeak.org 19 Oct '18

19 Oct '18

Chris Muller uploaded a new version of Chronology-Core to project The Inbox: http://source.squeak.org/inbox/Chronology-Core-cmm.13.mcz ==================== Summary ==================== Name: Chronology-Core-cmm.13 Author: cmm Time: 17 October 2018, 4:04:08.832696 pm UUID: 60718249-84a8-4dc2-aa94-4ba5c8e5addc Ancestors: Chronology-Core-tcj.12 Fix DateAndTime today asDate = Date today even when not in GMT. =============== Diff against Chronology-Core-tcj.12 =============== Item was changed: ----- Method: Timespan>>= (in category 'ansi protocol') ----- = comparand ^ self class = comparand class + and: [((self noTimezone and: [comparand noTimezone]) - and: [((self noTimezone or: [ comparand noTimezone ]) ifTrue: [ self start hasEqualTicks: comparand start ] ifFalse: [ self start = comparand start ]) and: [ self duration = comparand duration ] ] .!

4 5

[SqueakMap][5.2] Entry for SQLite3
by H. Hirzel 19 Oct '18

19 Oct '18

Hello all Following up on the mail of Benoit about databases. I'd like to construct an entry for SQLite3 for the Squeak release 5.2. I understand that it needs FFI, the FFI entry is in SqueakMap. According to SQLite http://wiki.squeak.org/squeak/6367 an up to date repository seems to be this one http://smalltalkhub.com/#!/~MilanVavra/SqueakSQLite3 These instructions (2016) are fairly recent https://milanvavra.wordpress.com/2016/08/12/squeak-5-0-using-sqlite3/ Loading this code into Squeak 5.2 works. All tests are green. Do you have comments?, update information? Regards Hannes

1 1

Code repositories
by Benoit St-Jean 19 Oct '18

19 Oct '18

Since Squeak 5.2 is out, I thought it might be a good excuse to revisit some database stuff... But... What is the "official"/preferred Squeak code repository ? There is code on SqueakSource, GitHub, http://source.squeak.org, SmalltalkHub, SqueakSource3, etc. Do I have to visit each of those places to find the latest package XYZ I want to test/port ? And when I do migrate some code to Squeak 5.2, what is the "official" code repository where I should publish it? P.S. If there is no centralized code repository for Squeak, it might be a good idea to create one. How many times was I frustrated to find code that was pharo-centric and that wouldn't load in Squeak because it was *explicitly* written for Pharo without any regard for dialect-compatibility ? P.P.S. I couldn't find any tool for GitHub publishing in the out-of-the-box Squeak 5.2 image. Is GitHub a long-term goal for publishing code & code management ? In other words, where should we ALL publish our code for Squeak apps/frameworks ?

2 1

Re: [squeak-dev] ProvideAnswerNotification and UIManager
by David T. Lewis 19 Oct '18

19 Oct '18

+1 for moving it to trunk, and thanks for waiting until after the 5.2 release was done. The changes load without problems in 5.2, work well, and they have good unit test coverage. These updates let a UIManager be responsible for dispatching the user interface requests, which is exactly the right thing to do. See class comment: UIManager is a dispatcher for various user interface requests, such as menu and dialog interactions. An instance of UIManager is associated with each Project to implement the appropriate functions for Morphic, MVC or other user interfaces. Thanks, Dave On Thu, Oct 18, 2018 at 05:56:28PM +0100, patrick.rein(a)hpi.uni-potsdam.de wrote: > Hi everyone, > > some of you might remember that I proposed a changeset for refactoring the signaling and handling of ProvideAnswerNotification (ProvideAnswerNotification and UIManager ( http://forum.world.st/ProvideAnswerNotification-and-UIManager-td5081488.html) and original text below). David already looked at it briefly and I would like to merge the changes in the near future (before it gets lost), so I would like to ask for other opinions before adding it. :) > > Bests > Patrick > > Hi everyone, > > recently I noticed that the method BlockClosure>>valueSupplyingAnswer: (and related ones) do > not work on all method of UIManager. When I looked into the issue I noticed that the signaling of > ProvideAnswerNotification is not done in the UIManagers but in the classes implementing the > actual user interfaces for the corresponding queries (e.g. MenuMorph and PopUpMenu). This > scattered the ProvideAnswerNotification logic throughout different packages and classes and > might have lead to the oversights. > > The attached changeset is a refactoring of this mechanism which moves the corresponding > logic into the UIManagers. Unfortunately, this required some code duplication but at least it is > contained with the UIManager. On the plus side the code is contained in the UIManagers and > all methods should be covered now. > > As I am not very familiar with the original intend and responsibilities of the UIManagers I wanted > to ask whether anyone has any thoughts on that change. > > Thanks and bests > Patrick > ["ProvideAnswerNotification.2.cs"] >

1 0

The Inbox: Chronology-Core-cmm.14.mcz
by commits＠source.squeak.org 18 Oct '18

18 Oct '18

Chris Muller uploaded a new version of Chronology-Core to project The Inbox: http://source.squeak.org/inbox/Chronology-Core-cmm.14.mcz ==================== Summary ==================== Name: Chronology-Core-cmm.14 Author: cmm Time: 17 October 2018, 10:07:14.485014 pm UUID: 5d93900c-4a4e-4a4e-80f3-800dbdb07d0b Ancestors: Chronology-Core-tcj.12 - A fix and optimization of Timespan>>#=. Both elements being compared must have the same timezone (or same state of #noTimezone) in order to take advantage of the optimized #hasEqualTicks: comparison. Otherwise (if different timezones), a full comparison of their starts (via #=) is needed. - There was a mention of this optimization put into the class comment. This level of detail may be a bit tedious for users to read at that level, so Brents original comment was restored. =============== Diff against Chronology-Core-tcj.12 =============== Item was changed: Magnitude subclass: #Timespan instanceVariableNames: 'start duration' classVariableNames: '' poolDictionaries: '' category: 'Chronology-Core'! + !Timespan commentStamp: 'cmm 10/17/2018 22:00' prior: 0! + I represent a duration starting on a specific DateAndTime.! - !Timespan commentStamp: 'bf 2/18/2016 14:43' prior: 0! - I represent a duration starting on a specific DateAndTime. - - If my start has an offset identical to my #defaultOffset then comparisons ignore timezone offset.! Item was changed: ----- Method: Timespan>>= (in category 'ansi protocol') ----- = comparand + ^ self class = comparand class + and: [(((self noTimezone and: [comparand noTimezone]) or: [self start offset = comparand start offset]) + ifTrue: [ self start hasEqualTicks: comparand start ] + ifFalse: [ self start = comparand start ]) + and: [ self duration = comparand duration ] ] - ^ self class = comparand class - and: [((self noTimezone or: [ comparand noTimezone ]) - ifTrue: [ self start hasEqualTicks: comparand start ] - ifFalse: [ self start = comparand start ]) - and: [ self duration = comparand duration ] ] .!

4 7

A small cursor glitch
by Stéphane Rollandin 18 Oct '18

18 Oct '18

When a halo in invoked on a morph which is right over a text with focus, the cursor keeps its text form even within the halo handles. I have fixed this for my own usage in the attached code, but I do not know if it is the proper way to go, or if this has unwanted side effects (I guess it does). The culprit is in method #dispatchFocusEventAllOver:with: in MorphicEventDispatcher Stef

2 2

The Inbox: Chronology-Core-cmm.15.mcz
by commits＠source.squeak.org 18 Oct '18

18 Oct '18

Chris Muller uploaded a new version of Chronology-Core to project The Inbox: http://source.squeak.org/inbox/Chronology-Core-cmm.15.mcz ==================== Summary ==================== Name: Chronology-Core-cmm.15 Author: cmm Time: 18 October 2018, 3:06:21.843002 pm UUID: 388f1031-54aa-49b4-a070-726ae1d5f489 Ancestors: Chronology-Core-tcj.12 - Add Timespan>>#beCanonical so that dates created via "myDateAndTime asDate" can be made canonical. - A fix and optimization of Timespan>>#=. Both elements being compared must have the same timezone (or same state of #noTimezone) in order to take advantage of the optimized #hasEqualTicks: comparison. Otherwise (if different timezones), a full comparison of their starts (via #=) is needed. - There was a mention of this optimization put into the class comment. This level of detail may be a bit tedious for users to read at that level, so Brents original comment was restored. =============== Diff against Chronology-Core-tcj.12 =============== Item was changed: Magnitude subclass: #Timespan instanceVariableNames: 'start duration' classVariableNames: '' poolDictionaries: '' category: 'Chronology-Core'! + !Timespan commentStamp: 'cmm 10/17/2018 22:00' prior: 0! + I represent a duration starting on a specific DateAndTime.! - !Timespan commentStamp: 'bf 2/18/2016 14:43' prior: 0! - I represent a duration starting on a specific DateAndTime. - - If my start has an offset identical to my #defaultOffset then comparisons ignore timezone offset.! Item was changed: ----- Method: Timespan>>= (in category 'ansi protocol') ----- = comparand + ^ self class = comparand class + and: [(((self noTimezone and: [comparand noTimezone]) or: [self start offset = comparand start offset]) + ifTrue: [ self start hasEqualTicks: comparand start ] + ifFalse: [ self start = comparand start ]) + and: [ self duration = comparand duration ] ] - ^ self class = comparand class - and: [((self noTimezone or: [ comparand noTimezone ]) - ifTrue: [ self start hasEqualTicks: comparand start ] - ifFalse: [ self start = comparand start ]) - and: [ self duration = comparand duration ] ] .! Item was added: + ----- Method: Timespan>>beCanonical (in category 'squeak protocol') ----- + beCanonical + "Make the receiver a canonical Date (or Month or Year) instead of a timespan of my duration starting at a specific local time. Canonical are the most common use of Dates in applications." + self stripTimezone! Item was added: + ----- Method: Timespan>>stripTimezone (in category 'squeak protocol') ----- + stripTimezone + "Chronology preserves Timespans that are extracted from DateAndTime's, making Dates, Months and Years in Squeak able to represent a true Timespan of those durations starting at a specific local DateAndTime. In case a canonical version is needed, make the receiver independent of any Timezone by removing it." + start primOffset: self class defaultOffset!

2 1

Deprecated long overdue in 5.3
by karl ramberg 18 Oct '18

18 Oct '18

Hi, We have several methods that have been deprecated for several releases. We should prepare for removal of these now in the beginning of 5.3 Best, Karl

5 4

ProvideAnswerNotification and UIManager
by patrick.rein＠hpi.uni-potsdam.de 18 Oct '18

18 Oct '18

Hi everyone, some of you might remember that I proposed a changeset for refactoring the signaling and handling of ProvideAnswerNotification (ProvideAnswerNotification and UIManager ( http://forum.world.st/ProvideAnswerNotification-and-UIManager-td5081488.html) and original text below). David already looked at it briefly and I would like to merge the changes in the near future (before it gets lost), so I would like to ask for other opinions before adding it. :) Bests Patrick Hi everyone, recently I noticed that the method BlockClosure>>valueSupplyingAnswer: (and related ones) do not work on all method of UIManager. When I looked into the issue I noticed that the signaling of ProvideAnswerNotification is not done in the UIManagers but in the classes implementing the actual user interfaces for the corresponding queries (e.g. MenuMorph and PopUpMenu). This scattered the ProvideAnswerNotification logic throughout different packages and classes and might have lead to the oversights. The attached changeset is a refactoring of this mechanism which moves the corresponding logic into the UIManagers. Unfortunately, this required some code duplication but at least it is contained with the UIManager. On the plus side the code is contained in the UIManagers and all methods should be covered now. As I am not very familiar with the original intend and responsibilities of the UIManagers I wanted to ask whether anyone has any thoughts on that change. Thanks and bests Patrick ["ProvideAnswerNotification.2.cs"]

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
13
Older →