From commits at source.squeak.org Sat Aug 1 03:12:19 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sat, 1 Aug 2020 03:12:19 0000 Subject: [squeak-dev] The Trunk: Collections-eem.905.mcz Message-ID: Eliot Miranda uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-eem.905.mcz ==================== Summary ==================== Name: Collections-eem.905 Author: eem Time: 31 July 2020, 8:12:16.99079 pm UUID: 41110ea1-5c9c-40e4-b5fa-156999451cae Ancestors: Collections-eem.904 Provide SequenceableCollection>>indicesOfSubCollection:[startingAt:] Add primitiveFetchMourner for ephemerons. Tidy up restartFinalizationProcess and name the finalization process for the process inspector. =============== Diff against Collections-eem.904 =============== Item was added: + ----- Method: SequenceableCollection>>indicesOfSubCollection: (in category 'accessing') ----- + indicesOfSubCollection: subCollection + "Answer an Array (possibly empty) of all the indices of subCollection in the receiver." + + ^self indicesOfSubCollection: subCollection startingAt: 1! Item was added: + ----- Method: SequenceableCollection>>indicesOfSubCollection:startingAt: (in category 'accessing') ----- + indicesOfSubCollection: subCollection startingAt: initialIndex + "Answer an Array (possibly empty) of all the indices of subCollection in the receiver starting at + initialIndex. N.B. This does not (yet) use Boyer-Moore to skip over unnecessary alignments." + + ^Array streamContents: + [:s| | index | + index := initialIndex - 1. + [(index := self indexOfSubCollection: subCollection startingAt: index + 1) = 0] whileFalse: + [s nextPut: index]]! Item was added: + ----- Method: WeakArray class>>primitiveFetchMourner (in category 'private') ----- + primitiveFetchMourner + "Answer the next mourner in the VM's queue of objects to be finalized. + The queue contains weak arrays and ephemerons. If the primitive is + not implemented, raise an error telling people to upgrade the VM. If + implemented, the primitive fails if the queue is empty, with the error + code #'not found'. Primitive. Essential." + + + ec ifNil: [^self error: 'The primitiveFetchMourner primitive is missing.\Please upgrade your virtual machine to one that has the primitive.' withCRs]. + ^nil! Item was changed: ----- Method: WeakArray class>>restartFinalizationProcess (in category 'private') ----- restartFinalizationProcess "kill any old process, just in case" + FinalizationProcess ifNotNil: + [FinalizationProcess terminate. + FinalizationProcess := nil]. - FinalizationProcess - ifNotNil: [FinalizationProcess terminate. - FinalizationProcess := nil]. FinalizationSemaphore := Smalltalk specialObjectsArray at: 42. FinalizationDependents ifNil: [FinalizationDependents := WeakArray new: 10]. FinalizationLock := Semaphore forMutualExclusion. FinalizationProcess := [self finalizationProcess] + forkAt: Processor userInterruptPriority + 1 + named: 'the finalization process'! - forkAt: Processor userInterruptPriority! From forums.jakob at resfarm.de Sat Aug 1 12:27:56 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Sat, 1 Aug 2020 14:27:56 +0200 Subject: [squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...") In-Reply-To: References: <23539013-D464-4CC6-89B2-26B451C2338E@sonic.net> Message-ID: Hi Chris, Chris Muller schrieb am Fr., 31. Juli 2020, 22:47: > > >> *but* >> >> It would be a problem in dialogues with several input fields though; see >> for example the SqueakMap edit tool. > > > That's different. Not modal. Just like the code browser, where you don't > want Cmd+s to close the code browser. But for modal dialogs, yes, ... > What do you think about windows that are input requesting dialogs, but not modal, as in: prevents other interactions while it is open? The commit dialog of the Git Browser falls into this category. But even though the Monticello save dialog will claim to be modal if its process is interrupted, it isn't really since you can do other things while it is open. So you could also answer with the Monticello save window in mind. Or the Monticello merge tool, which does not have text input for a change. Kind regards, Jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: From forums.jakob at resfarm.de Sat Aug 1 12:35:36 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Sat, 1 Aug 2020 14:35:36 +0200 Subject: [squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...") In-Reply-To: References: <23539013-D464-4CC6-89B2-26B451C2338E@sonic.net> Message-ID: Hi Tim, tim Rowledge schrieb am Fr., 31. Juli 2020, 19:57: It would be a problem in dialogues with several input fields though; see for example the SqueakMap edit tool. It could be a problem for dialogues where we allow longer text that might have CRs. We do need to keep it possible to close/accept/cancel with just keyboard input as well. A related topic might be the absence of tab navigation in Squeak. In many GUI systems there is a key to move the focus to the next widget, mostly the tab key. There is no such thing in Squeak, is it? Kind regards, Jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.withers at pm.me Sat Aug 1 15:54:59 2020 From: robert.withers at pm.me (Robert Withers) Date: Sat, 01 Aug 2020 15:54:59 +0000 Subject: [squeak-dev] Debugging of other processes with wait In-Reply-To: References: <60A16E3F-BDE8-4FA9-85D9-9F5441F5B751@gmail.com> <5729379a-9559-e8c7-1233-218e18353293@pm.me> Message-ID: Hi Jakob, On 7/28/20 3:50 PM, Jakob Reschke wrote: > Forward reply to the list... seems like something has changed in the > Gmail interface and I have not yet adapted to it. > > Am Do., 23. Juli 2020 um 20:01 Uhr schrieb Robert Withers > : >> Although the Promise defined in Kernel-Processes has #wait protocol, this is really an anathema to Promise-style control flow. The #whenResolved: protocol should be used to register a reactor and no waits should occur. >> [...] >> Promise-style control flow does not use mutexes nor semaphores. So I believe the fundamental model here is misused. >> [...] >> So it is your intention to "move away from promise-style control flow." then I would suggest not using a Promise. >> > That's right, but right now I have some dialogs implemented in a > Promise style and want to implement a use case without promise style, > so I have to literally adapt when invoking the dialog if I don't want > to write all of it anew immediately. I am faced with a similar porting activity to bring SSL and SSH over onto the ThunkStack architecture. How do you dialogs function with a promise interface? Could you describe what you have done here, please? > Our current Kernel Promise is a two-headed beast: Interesting. > for one it wants to > be a Promises/A+ implementation, Even this is a concurrency model with #send:/#then: protocols. > but originally it's purpose seems to > be only to support #future sends. Which seems to have nothing at all to do with whether it is a Future. It's a Promise. This that you call future, is merely scheduling after a delay, right? > Promises/A+ is targeted at > asynchrony in single-thread languages like JavaScript, This is a definite concurrency protocol which allows for multi-agent interaction. I would suggest it is inherently a concurrency model, though it may not be explicit about single threaded vats. Smalltalk is also single-threaded on the processor. > while futures are for multi-thread languages like Smalltalk. I see the #then: protocol as the model for promises in multi-thread environments. Not the scheduling. > So Kernel Promise now > tries to serve both single-thread computing (UI process only) and > multi-thread computing (multiple Smalltalk processes). This multi-thread goal is the source of the #wait protocol, yes? I would like to suggest integrating PromisesLocal into the trunk image. I will send a separate email, describing my proposal. Kindly, rabbit From robert.withers at pm.me Sat Aug 1 16:09:12 2020 From: robert.withers at pm.me (Robert Withers) Date: Sat, 01 Aug 2020 16:09:12 +0000 Subject: [squeak-dev] [Proposed] include PromisesLocal in trunk Message-ID: <7c8ad646-d5c3-9da8-93fc-0ef6be932163@pm.me> Good afternoon! I wish to offer a proposal for discussion to include PromisesLocal into trunk and to replace the implementation of Promise/BrokenPromise with PromiseERefs and BrokenERefs. The underlying concurrency model has explicit use of an event loop in PromisesLocal. The code size is minimal but adds the Promises/A+ specification to Squeak, that can be extended into a remote reference solution and an Agent communications architecture. Exceptions are processed. I want to define a VatSemaphore that allows the user to #wait/#signal, and they get 'immediate' control flow which most folks find as a valid way to describe steps taken.Under the covers the VatSemaphore is connected to the Vat, as an element in a forthcoming continuationPool. So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the continuation is captured and placed in the pool and the vat's event loop continues with the next event. When #signal is sent to this VatSemaphore, the continuation is scheduled: in the queue and removed from the pool. The event loop will process the continuation. >> On 7/28/20 3:41 PM, Jakob Reschke wrote: >> My other suspicion is that we would nevertheless need an extended >> debugger to deal well with such eventual control flow. A debugger >> with a "step to resolution" or so that steps to the point where the >> messages are eventually answered, or the receiver even activated. > I think that this is a great idea! Research in this direction would be AWESOME! On 8/1/20 11:39 AM, Robert Withers wrote: >> On 7/28/20 3:41 PM, Jakob Reschke wrote: >> Current Kernel Promises are also not good at that without sprinkling >> breakpoints... This and the dreadful error handling ("well so I >> forgot the block argument for the callback again and got an error >> from value:, now how do I find out in the debugger which method even >> contains my wrong block?!?" > What if the debugger could allow you to browse reactor creation > methods? Where is the closure created? I can imagine an implementation of EIO (http://wiki.erights.org/wiki/EIO_Redesign), Eventual I/O, that has a #whenAvailable: semantic. Then the UI event loop is just an EInputStream and we could flip the entire system over to using a promise architecture. Kindly, rabbit From ma.chris.m at gmail.com Sat Aug 1 23:22:07 2020 From: ma.chris.m at gmail.com (Chris Muller) Date: Sat, 1 Aug 2020 18:22:07 -0500 Subject: [squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...") In-Reply-To: References: <23539013-D464-4CC6-89B2-26B451C2338E@sonic.net> Message-ID: It used to be that Cmd+s would remember the contents of text fields in windows, so that if I then made further modifications to it which I *then* change my mind about, I could press Cmd+l (lowercase L), to restore it to the last-accepted state. I really miss that in Workspaces and inspectors. But it should never close a multifield dialog, IMO. Maybe it shouldn't even for FillInTheBlank either, for consistency. - Chris On Sat, Aug 1, 2020 at 7:28 AM Jakob Reschke wrote: > Hi Chris, > > Chris Muller schrieb am Fr., 31. Juli 2020, 22:47: > >> >> >>> *but* >>> >>> It would be a problem in dialogues with several input fields though; see >>> for example the SqueakMap edit tool. >> >> >> That's different. Not modal. Just like the code browser, where you >> don't want Cmd+s to close the code browser. But for modal dialogs, yes, ... >> > > What do you think about windows that are input requesting dialogs, but not > modal, as in: prevents other interactions while it is open? The commit > dialog of the Git Browser falls into this category. But even though the > Monticello save dialog will claim to be modal if its process is > interrupted, it isn't really since you can do other things while it is > open. So you could also answer with the Monticello save window in mind. Or > the Monticello merge tool, which does not have text input for a change. > > Kind regards, > Jakob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Sun Aug 2 09:42:10 2020 From: gettimothy at zoho.com (gettimothy) Date: Sun, 02 Aug 2020 05:42:10 -0400 Subject: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye Message-ID: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> Hi folks, This probably holds for 5.3 install too. In the preferences wizard, the extras stuff, the Install Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" iirc, from the pharo discord, SmalltalkHub is going away. You will probably need a different repo. cordially, tty -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.withers at pm.me Sun Aug 2 12:55:12 2020 From: robert.withers at pm.me (Robert Withers) Date: Sun, 02 Aug 2020 12:55:12 +0000 Subject: [squeak-dev] [Proposed] include PromisesLocal in trunk In-Reply-To: <7c8ad646-d5c3-9da8-93fc-0ef6be932163@pm.me> References: <7c8ad646-d5c3-9da8-93fc-0ef6be932163@pm.me> Message-ID: <265e61a3-00a4-ee10-eb88-3c3741418cb7@pm.me> Hi all'y'all! Here is a textbook on Promises, for your understanding. > [Inspired by functional programming, one of the major distinctions between different interpretations of this construct have to do with pipelineing or composition. Some of the more popular interpretations of futures/promises make it possible to chain operations, or define a pipeline of operations to be invoked upon completion of the computation represented by the future/promise. This is in contrast to callback-heavy or more imperative direct blocking approaches.] http://dist-prog-book.com/chapter/2/futures.html K, r On 8/1/20 12:09 PM, Robert Withers wrote: > Good afternoon! > > I wish to offer a proposal for discussion to include PromisesLocal into > trunk and to replace the implementation of Promise/BrokenPromise with > PromiseERefs and BrokenERefs. The underlying concurrency model has > explicit use of an event loop in PromisesLocal. The code size is minimal > but adds the Promises/A+ specification to Squeak, that can be extended > into a remote reference solution and an Agent communications > architecture. Exceptions are processed. > > I want to define a VatSemaphore that allows the user to #wait/#signal, > and they get 'immediate' control flow which most folks find as a valid > way to describe steps taken.Under the covers the VatSemaphore is > connected to the Vat, as an element in a forthcoming continuationPool. > So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the > continuation is captured and placed in the pool and the vat's event loop > continues with the next event. When #signal is sent to this > VatSemaphore, the continuation is scheduled: in the queue and removed > from the pool. The event loop will process the continuation. > >>> On 7/28/20 3:41 PM, Jakob Reschke wrote: >>> My other suspicion is that we would nevertheless need an extended >>> debugger to deal well with such eventual control flow. A debugger >>> with a "step to resolution" or so that steps to the point where the >>> messages are eventually answered, or the receiver even activated. >> >> I think that this is a great idea! > > Research in this direction would be AWESOME! > > On 8/1/20 11:39 AM, Robert Withers wrote: > >>> On 7/28/20 3:41 PM, Jakob Reschke wrote: >>> Current Kernel Promises are also not good at that without sprinkling >>> breakpoints... This and the dreadful error handling ("well so I >>> forgot the block argument for the callback again and got an error >>> from value:, now how do I find out in the debugger which method even >>> contains my wrong block?!?" >> >> What if the debugger could allow you to browse reactor creation >> methods? Where is the closure created? > > I can imagine an implementation of EIO > ( > http://wiki.erights.org/wiki/EIO_Redesign > ), Eventual I/O, that has a > #whenAvailable: semantic. Then the UI event loop is just an EInputStream > and we could flip the entire system over to using a promise architecture. > > Kindly, > rabbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.withers at pm.me Sun Aug 2 13:48:31 2020 From: robert.withers at pm.me (Robert Withers) Date: Sun, 02 Aug 2020 13:48:31 +0000 Subject: [squeak-dev] [Proposed] include PromisesLocal in trunk In-Reply-To: <265e61a3-00a4-ee10-eb88-3c3741418cb7@pm.me> References: <7c8ad646-d5c3-9da8-93fc-0ef6be932163@pm.me> <265e61a3-00a4-ee10-eb88-3c3741418cb7@pm.me> Message-ID: <99b4ede5-9716-c646-8c9a-dbe9b6885a89@pm.me> Hello, there, In reading the chapter on Promises, in the section on the E programming language, of which PromisesLocal is modeled, the following needs clarification: > Subsequent messages can also be eventually sent to a promise before it is resolved. In this case, these messages are queued up and forwarded once the promise is resolved. The messages are not queued up at the local promise, pending forwarding to the eventual result; they are forwarded to a promise, local to the computation. This is mainly important once you have introduced remote promises (PromisesRemote). Messages are sent to the computation and they queue up local, for execution upon the eventual value, #whenMoreResolved:. K, r NB: here is a chained message sending eventually, with Promises. > ((10 eventual factorial / 100) * 25) > whenResolved: [:i | i value]. On 8/2/20 8:55 AM, Robert Withers wrote: > Hi all'y'all! > > Here is a textbook on Promises, for your understanding. > >> [Inspired by functional programming, one of the major distinctions between different interpretations of this construct have to do with pipelineing or composition. Some of the more popular interpretations of futures/promises make it possible to chain operations, or define a pipeline of operations to be invoked upon completion of the computation represented by the future/promise. This is in contrast to callback-heavy or more imperative direct blocking approaches.] > > http://dist-prog-book.com/chapter/2/futures.html > K, r > > On 8/1/20 12:09 PM, Robert Withers wrote: > >> Good afternoon! >> >> I wish to offer a proposal for discussion to include PromisesLocal into >> trunk and to replace the implementation of Promise/BrokenPromise with >> PromiseERefs and BrokenERefs. The underlying concurrency model has >> explicit use of an event loop in PromisesLocal. The code size is minimal >> but adds the Promises/A+ specification to Squeak, that can be extended >> into a remote reference solution and an Agent communications >> architecture. Exceptions are processed. >> >> I want to define a VatSemaphore that allows the user to #wait/#signal, >> and they get 'immediate' control flow which most folks find as a valid >> way to describe steps taken.Under the covers the VatSemaphore is >> connected to the Vat, as an element in a forthcoming continuationPool. >> So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the >> continuation is captured and placed in the pool and the vat's event loop >> continues with the next event. When #signal is sent to this >> VatSemaphore, the continuation is scheduled: in the queue and removed >> from the pool. The event loop will process the continuation. >> >>>> On 7/28/20 3:41 PM, Jakob Reschke wrote: >>>> My other suspicion is that we would nevertheless need an extended >>>> debugger to deal well with such eventual control flow. A debugger >>>> with a "step to resolution" or so that steps to the point where the >>>> messages are eventually answered, or the receiver even activated. >>> >>> I think that this is a great idea! >> >> Research in this direction would be AWESOME! >> >> On 8/1/20 11:39 AM, Robert Withers wrote: >> >>>> On 7/28/20 3:41 PM, Jakob Reschke wrote: >>>> Current Kernel Promises are also not good at that without sprinkling >>>> breakpoints... This and the dreadful error handling ("well so I >>>> forgot the block argument for the callback again and got an error >>>> from value:, now how do I find out in the debugger which method even >>>> contains my wrong block?!?" >>> >>> What if the debugger could allow you to browse reactor creation >>> methods? Where is the closure created? >> >> I can imagine an implementation of EIO >> ( >> http://wiki.erights.org/wiki/EIO_Redesign >> ), Eventual I/O, that has a >> #whenAvailable: semantic. Then the UI event loop is just an EInputStream >> and we could flip the entire system over to using a promise architecture. >> >> Kindly, >> rabbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Sun Aug 2 14:40:48 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 02 Aug 2020 14:40:48 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1779 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f26d0706f4f6_13ff2a4f19a10145662@travis-tasks-84877b9cc8-hxxvg.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1779 Status: Errored Duration: 17 mins and 32 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/714207381?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forums.jakob at resfarm.de Sun Aug 2 20:12:54 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Sun, 2 Aug 2020 22:12:54 +0200 Subject: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> Message-ID: Probably related thread: http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev : > > Hi folks, > > This probably holds for 5.3 install too. > > In the preferences wizard, the extras stuff, the Install Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" > > iirc, from the pharo discord, SmalltalkHub is going away. > > You will probably need a different repo. > > cordially, > > tty > > From vanessa at codefrau.net Mon Aug 3 01:47:34 2020 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Sun, 2 Aug 2020 18:47:34 -0700 Subject: [squeak-dev] Squeak News from 2001 Message-ID: Hi all, Squeak News was a multimedia e-zine published by Tansel Ersavas in 2001 as Squeak images on CD-ROM. Each issue contains contributions from many people in our community. I build a web viewer using SqueakJS: https://smalltalkzoo.computerhistory.org/SqueakNews/index.html The source code is on GitHub: https://github.com/squeak-smalltalk/squeaknews Contributions welcome! If you find something that doesn't work correctly, please file a bug report on github. Enjoy! Vanessa I'm copying the table of contents below: Volume 1 Issue 1, July 2001 Open Issue #1 Cover PageDid you have fun with our cover page? We certainly did. A little heavy with animation, a little slow on slower machines, but still enjoyable. So if at any point you would like to return to it please feel free.Our First IssueWhat On Earth Are We Doing? by Tansel ErsavasWell, now you know. Read all about it in this editorial note.This month in the Squeak World by Bijan ParsiaThis month's news include summaries of the activity of the Squeak list and the Squeak foundation list. Squeak in the press and Squeak Central's new move is high on the agenda.Mini E-View with Dan IngallsDo not miss this mini E-view with Dan Ingalls about the latest move of Squeak Central and future of Squeak!A Most Unusual Method Finder by Ted KaehlerIn this essay Ted takes us through the Method finder and the idea behind it. Ted explains how he started writing the method finder, how it works, how the symbol table is searched, how "methods by example" works and how method finder handles an exhaustive search without causing any damage to the system.Interview with John MaloneyPart 1: Before AppleIn the first part of this in-depth interview, we talked with John about the early days: how he started working with Smalltalk, his early Xerox days, the origins of Celeste, his experience with other systems, constraint based programming, Self and the birth of Morphic.VMMaker - a tool to make VM making simpler by Tim RowledgeIn this article, Tim explains the VmMaker and the motive behind it. Tim's VmMaker makes the process of generating VMs much easier. Tim explains the usage of VmMaker and he states possible enhancements to it.The Foundations of SqueakNOS by the SqueakNOS team / Luciano NotarfrancescoSqueakNOS is an ambitious project that aims to strip that useless huge nappy padded underwear of computers that is called an "operating system" and replace it with a layer all written in Squeak! Here the SqueakNOS team explain how they intend to do it, what they have done so far, how they have done it, and what they aim to do.Squeak Tweaks: Celeste as a Mailing List Summarizer by Bijan ParsiaIn this corner of the e-zine, Bijan will show us how to tweak Squeak with interesting insights.In his first article Bijan takes Celeste and turns it into a mail list summarizer! He explains the need for the mail summarizer (after all he volunteered for the Squeak News monthly email summaries!) and step by step explains how Celeste is turned into a handy mail summarizer sidekick. After reading this article you will have a good idea about how he can categorize and sift through the enormous amount of email that Squeak list generates with a little help from his new Celeste-MLS!Squeak Documentation InitiativeSqueak Documentation initiative is a Squeak News sponsored activity that will start with this issue. Here we will explain mechanisms and ask for volunteers for this initiative. The goal is to create a giant living reference manual and a reference server that any Squeak that is on the net can hook up to and access to on-line documantaion. This documentation will be in a form that can be embedded in any image and will have built in mechanisms to update itself when changes are made and post these updates to a central server or other peers. Another useful document is a user guide which will also be semi-automatically generated. Documentation swiki pages will be used to capture most additions and modifications to the documentation. More details will soon be available from the Squeak News site.Fun with Squeak: Learn to Juggle with Squeak by Tansel ErsavasIn this article Tansel takes you to a journey that will juggle two things at once: learning juggling while writing a tutorial that teaches juggling. It is a meta-juggling tutorial that is a lot of fun. Most aspects of juggling from choosing the right balls to how not to juggle with raw eggs are clearly illustrated with animated examplesSqueak Notebook by Torsten BergmannA little example of how a SqueakBook can look like a notebookBest of Bob's SuperSwiki: Squeak or How the Mouse RoarsEach month we will feature a project published in Bob's super Swiki or other public Super Swikis. This month we feature the first part of Torsten Bergman's HTMR: Squeak or How the Mouse Roars' series.Squeak Graphics by Ali ChamasGraphics created by Ali Chamas using Squeak captured the attention of many people and some of these graphics were featured in web sites such as flipcode.com. See them yourself.This Month's Quiz: Detecting an Alarm via Email from a Remote LocationTributes: Pat Caudill and Jerry ArchibaldThis month we have lost 2 Smalltalkers. Pat Caudill (1945-2001) passed away June 14, 2001, and Jerry Archibald (1940-2001) passed away June 22, 2001. All Issues Volume 1 Issue 2, 15 August 2001 Open Issue #2 Focus on BeginnersStarting with this issue we will focus on beginners and every issue of Squeak News will feature at least one article targeted at beginners. This month we feature two articles that would help beginners. You will also find in this issue very interesting articles about hardware that can run Squeak, a very interesting user interface framework for UI development specifically tailored towards PDAs and Kiosk style applications. The Squeak Tweaks corner will feature a quickie HTML editor. For the diehards who are determined to rip the operating system under Squeak the current installment of the SqueakNOS series is "Story of the Quake Packet". You will also find the conclusion of the Juggling article and continuation of our in-depth interview with John Maloney.Squeak Related NewsThis month's news include summaries of the activity of the Squeak list and the Squeak foundation list and our report on fun new hardware to play with SqueakMonthly digest of the Squeak Mailing list by Bijan ParsiaEvery month Bijan summarizes the Squeak mailing list painstakingly by organizing postings under threads with commentary using home-bred tools that he developed. (and explained some of them in the July issue) If you are busy and can't follow the fast pace of the Squeak list this is the column to read! This section will be emailed to our email subscribers as well as posted on the on the web.Mean Squeak MachinesIn these articles we chase our DynaBook dreams and look at some of the latest systems from super PDAs to desktop units that can run Squeak happily.Cool PeripheralsWe also investigate some peripherals that can enhance our Squeak experience from tablet-screens to solid-state USB disk units that are attached to key-rings.How to Begin Squeak by Tansel ErsavasThis article is the first of a series about Squeak that aims to take a person from the beginner stage to the level of a highly sophisticated programmer during the course of this (long) series. In this article, Tansel outlines basic concepts of object oriented approach and Squeak. He emphasizes differences between Squeak and most other languages, explains why it is harder for people who have been exposed to other languages to learn Squeak and suggests strategies that would accelerate the learning process.An Approach for Teaching and Learning Squeak by Michael GuenterMichael brings us the experience of a teacher and proposes an approach for learning and teaching Squeak. He defines different kinds of newbies and discusses best approach for them and elaborates on his "study buddies" idea which has already attracted interest.Control your Submorphs by Ted Kaehler and Andreas RaabIn this active article Ted and Andreas take us to a tour of the new layout mechanism of morphs recently introduced to Squeak by Andreas Raab. As nicely stated by Ted: "Why talk about something when you can see it in action", this article will come to life when playing with it very true to the soul of Squeak News.The second part of an In-depth Interview with John MaloneyIn the second part of this in-depth interview, John talks about the Apple days, the birth of Squeak, how Squeak became on open source project, and how his expectations were exceeded with community support. We also discussed with him about the past life of Morphic before Squeakt.A Minimal User Interface Toolkit for PDAs and Kiosks by Tansel ErsavasIn this article Tansel introduces us to a very basic set of tools that help us implement simple user interfaces especially suitable for point and click applications. These applications are more likely to be useful on environments where using Morphic is not feasible such as small PDAs and Kiosk applications that operate on hardware with limited resources and where the input is limited to a touch screen or stylus input.Story of a Quake Packet by the SqueakNOS teamDo you know what these naughty people at the SqueakNOS team do when their workmates go into a frenzy of playing Quake? They peep the network activity using nothing other than their naughtier collaborator Squeak! Read this captivating story of intrigue and deception, and find out all about those Quake packets that lurk at your network pipes while people are playing Quake!.Squeak Tweaks: A Quickie HTML Editor by Bijan ParsiaIn this corner of the e-zine, Bijan shows us how to tweak Squeak with interesting insights.In this article Bijan has a go at a quickly put together HTML editor which could be the beginning of a HTML editor liberator!Juggle with Squeak by Tansel ErsavasIn this part of this series Tansel finally puts his act together (almost), both about juggling, and finishing this tutorial, and the rest of the people can finally juggle. He still has to write about the beautification process though.Squeak Documentation initiativeSqueak Documentation initiative is a Squeak News sponsored activity that will continue with this issue. This month's initiative will be discussed on our documentation SWiki later when the documentation SWiki is up and running.Squeak quiz with surprize rewardsEvery month, we have a question that addresses a specific problem and collect all answers. We will then publish selected answers and declare one as the "editor's choice". The person who sent the selected solution will receive a mystery reward from us. All Issues Volume 1 Issue 3, 15 September 2001 Open Issue #3 Squeak for a Better World!We changed our theme to Squeak for a Better World after the tragic events of September 11. Read all about the shock, frustrations and ideas about Squeak for a better world.Focus: MultimediaThere is a lot in Squeak News this month. Close to the end of this month is the 5th anniversary of the day Squeak was placed on the Internet for the rest of the world to enjoy and we e-talked with Dan Ingalls about this most important event. The focus of this issue is Squeak and Multimedia and we have a significant amount of content about the subject. We feature two interactive demos: Squeak Cinema: A demo of the Squeak MPEG player, and SqueakAmp: The Squeak MP3 player. In addition we feature an article about the MPEG player of Squeak by John McIntosh, the full set of the active essays on studying computer music by Mark Guzdial and an article about PhotoSqueak by Juan Manuel Vuletich. Karl Ramberg's contribution is a short active essay about Art and Computers. Our beginners series focus is objects, messages and beyond. An example of system level programming in Squeak is given in the article "The SqueakNOS keyboard". We also solicited an article about one of the recent developments about Squeak GemStone connectivity and we are happy to feature this article about GemSqueak.Squeak Related NewsThis month's news include an E-view with Dan Ingalls, summaries of the activity of the Squeak list and John McIntosh' Essen STUG reports.Squeak's 5th Birthday! An e-view with Dan IngallsAfter looking at all the evidence we decided that the 25th September 1996 was the day Squeak was unleashed to us mortals (incidentally after about 9 months of incubation)! We declared this day to be Squeak's "birth" day. We asked Dan about that day, a little earlier, and a little later, and Dan answered!Monthly digest of the Squeak Mailing list by Bijan ParsiaEvery month Bijan summarizes the Squeak mailing list painstakingly by organizing postings under threads with commentary using home-bred tools that he developed. (and explained some of them in the July issue) If you are busy and can't follow the fast pace of the Squeak list this is the column to read! This section will be emailed to our email subscribers as well as posted on the on the web.The World of Squeak: Objects, Messages and Beyond by Tansel ErsavasThis article is the second installment of a series about Squeak that aims to take a person from the beginner stage to the level of a highly sophisticated programmer during the course of this (long) series. In this article, Tansel explains the basic concepts of Squeak such as objects, messages and relationships between objects.Active Essays for Studying Computer Music by Mark GuzdialIf Mark Guzdial isn't an institution, he should be made into one. Author/instigator/editor of the two current Squeak books, hacker of PWS & the original Swiki, hoster of Swikis, teacher of Squeak... He, his students, and his classes are always throwing out cool stuff for the rest of us. For his class on "Computer Music Implementation", he wrote a series of active essays, which cover everything from the built in Squeak sound tools to MIDI. Aside from being nicely written/constructed on interesting topics -- i.e., an enjoyable read -- they are great examples of active essays. Mark was kind enough to let us feature the entire series in Squeak News with a bonus introduction that puts these great active essays in perspective.MPEG: Finding a Fit by John McIntoshAmong all these activities that keeps us all informed about what is going on around the world, John found the time to write about that magical plug-in that enables us to play highly compressed video and from within the comforts of Squeak.Squeak CinemaA showcase of the MPEG player and some of Squeak's presentation abilities. It features a trailer of a movie to be released next year by 20th Century Fox (C) 20th. Century Fox. The main feature is named "The Killer Bean Part 2, The Party" short masterpiece by Jeff Lew, slighltly over 6 minutes. This is an animation fully done by the author himself in 3 years on one computer. After the movie was released on the net it was downloaded more than 1 million times and helped him to join to the ranks of Hollywood's magic makers and he has been involved in movies such as the Matrix and the Matrix 2. We wish to advise our audiance that the movie contains strong violance and people who can't watch coffee beans destroyed should refrain from watching the movie. Sorry? What? No we don't have any grudges against coffee in any shape and we haven't hired the killer bean for any jobs.SqueakAmp: Squeak's MP3 playerA demonstration of the MP3 playback ability of Squeak that is written by Bob Hartwig using the MPEG plug-in.Art, Computers by Karl RambergKarl tosses questions about Art and Computers and starts experimenting in this short and sweet active essay...The Conclusion of our In-depth Interview with John MaloneyIn the conclusion of this in-depth interview, we talked with John about Morphic, how it differed from the original Self Morphic, and what is in the crystal ball for Morphic. We also talked about the Disney days, some projects that John got involved and more...The Squeak Keyboard: An Introduction to Low Level Programming in SqueakNOS by the SqueakNOS teamThis article explains how Squeak handles keyboard programming from within SqueakNOS. Don't try this code at home! It will only work within SqueakNOS.PhotoSqueak: An Image Processing Framework by Juan Manuel VuletichWhat started as a school project may well turn out to be a powerful general purpose digital image processing system for Squeak. Learn all about it.GemSqueak: A Full Functional GemStone Client by Valeria MurgiaGemSqueak is a full featured and full functional GemStone client. Valeria Murgia with collaboration by Leandro Caniglia explains this exciting project. Keep an eye for their SqueakAttic OODB project as well.Book Summary: Squeak's First Book and MultimediaThis is the first book summary published in Squeak News and naturally it is about the first book on Squeak ever published.Globe by Torsten BergmannA cool demo of 3D on a background created by the author.Juggle with Squeak by Tansel ErsavasIn this part of the series Tansel beautifies the Juggling Scene and explains how to create a simple user interface for the Juggling demo.Squeak quiz with surprize rewardsThis month we will not have a Squeak quiz, instead we are preparing a Squeak Challenge All Issues Volume 1 Issue 4, 15 October 2001 Open Issue #4 *Powerful Ideas in the Classroom*Editor's NoteMonthly News:This month's news include summaries of the activity of the Squeak list and John McIntosh's OOPSLA trip reports.Monthly digest of the Squeak Mailing list by Bijan ParsiaEvery month Bijan summarizes the Squeak mailing list painstakingly by organizing postings under threads with commentary using home-bred tools that he developed. (and explained some of them in the July issue) If you are busy and can't follow the fast pace of the Squeak list this is the column to read! This section will be emailed to our email subscribers as well as posted on the on the web.OOPSLA Trip Reports by John McIntoshJohn is an avid follower and documenter of almost every event. We asked if he would allow his excellent OOPSLA trip reports that are published on his site to be included in Squeak News and he kindly allowed us to include them with the Squeak News e-zine. Once we merged these reports with pictures of Michael Rueger it turned out to be a lively digest, just like if you were there!FeaturesStronger Goals for Education by Alan KayIn this article Alan defines stronger goals for education and explains the role of Squeak in this picture. A must read for all parties who have an interest in education.Treasures Unearthed: Alan Kay's Active Essays and ArticlesWe used this opportunity to feature many of Alan's past articles and active essays. As always Alan was very generous in allowing us to reprint these immense treasures in our colorful format and we have tried to illustrate them a little as well. Authoring by Alan KayThis is the introduction published on SqueakLand.org. It is a short but a very powerful article summarizes the purpose and the origin of SqueakEToys and SimStories in Squeak by Alan KayThis is a well known active essay by Alan Kay also featured on SqueakLand.org. In this active essay Alan shows us how simple scripting can be used to explain ideas that can't easily be explained. It explains the power of the Etoy system, the concept of active essays, why Etoys are important to science and math, and how Etoys are envisioned to be used in such active essays to even encyclopedias. A must read and should be in the pockets of every trainer!Computers, Networks and Education by Alan KayIn this classic originally printed in Scientific American in September 1991 issue AlanScience Already IS Art! by Alan KayA short and sweet article originally written for The San Jose Museum of Technology brochure.We will also publish more of Alan Kay's articles next monthSqueak in the Open Charter School by B.J. Allen-ConnB.J. has been involved in teaching children about interactive computing environments since 1986. Benefit from her experience in teaching Squeak to children. There are several examples of students of the Open Charter School. Be sure to check them all.The Big Race! by Open Charter School studentsDon't miss this Grand Prix of cars developed by students racing to capture the elusive championships. The creativity of students shine when cars of all colors and shapes take on each other at the track!Interactive Web-based Modeling and Explorations by Naala BrewerIn this article Naala details her interactive web-based explorations with students during the course of her teaching of interactivity through Squeak.Etoy examples by various studentsCool examples of ingenious usage of Squeak Etoy system by students in 4th and 5th grades in the Open Charter School. Be inspired by their creativity!School Squeaking by Cathleen GalasCathleen teaches at the Seeds University Elementary School, which is the laboratory school for the Graduate School of Education and Information Studies, UCLA. As a teacher already experienced in introducing kids to the Microworlds logo she details her experience with Squeak and Squeak's advantages over other systems. Her illuminating observations and student feedback make an excellent case for Squeak's use in the classroom.Youngest Users of Squeak SpeakFeedback by some of the youngest users of SqueakEtoys: Squeak as an Authoring System for Kids (and Kids at Heart!!)We feature every tutorial we can find about the Etoy system by various authors. Enjoy them all!Squeak News Exclusive Interview with Kim RoseThis month we had a chance to talk to Kim Rose (co-Director of the Viewpoints Research Institute: now home of Squeak Central, long term member of the Squeak Central, co-editor of the book Squeak: Open Personal Computing and Multimedia) in depth about how she got involved in computing and Squeak, media and cognitive science, her interest and efforts in Squeak and kids, Apple days, Disney days, and post Disney. This month we will publish Part 1 of this 3 part series.Plugging in Squeak by Michael RuegerIn this article Michael takes us from the beginning and tells us how the Squeak plug-in came to life, where was it first used, how is it used and what is and what is not in the pipeline.As a courtesy to our subscribers we include the plug-in installers for various platforms for you to save you some download time.From objects to classes by Tansel ErsavasThis article is the third installment of a series about Squeak that aims to take a person from the beginner stage to the level of a highly sophisticated programmer during the course of this (long) series. In this article, Tansel explains the concept of a class, how classes and objects are related, and how classes are related to each other.A Minimal Multimedia Manager for PDAs and Kiosks by Tansel ErsavasThis article will be published on our SWiki later due to heavy commitments and health problems of the author. We apologize.Juggle with Squeak by Tansel ErsavasIn this part of the series Tansel finishes the demo and packages it with a gift wrap!Little ButterflyA little poem by a very sweet girl!Squeak's Most Wanted ListStarting this issue we will create a "Most Wanted list" for Squeak and offer some rewards. Since it will be on an SWiki page you are free to add your "most wanted feature or function" to the list. In every issue of Squeak we will recite the top of the list, newcomers to this list and report progress if any. This month there is a grand challenge: Target:Advance All Issues Volume 1 Issue 5, November 2001 Open Issue #5 *Future Technologies that may impact Squeak*EditorialThe Squeak Mailing List SummaryActually, this month it is not a summary, but an entire dump of all the mails in the mailing list.Future Technologies that may Impact Squeak by Tansel ErsavasIn this issue of Squeak News we decided to have a quick trip to the near future and come back with some gossip about what might impact Squeak and in what ways.Mean Squeak Machines: Futuristic ToysContinuing our future theme is the seciton on mean Squeak machines: Futuristic toys. Enjoy them!A Simple Task Management Tool by Tansel ErsavasThis article introducs a simple task management tool which could be used as a simple project management tool as well as a task scheduling tool.Alan Kay Treasure ChestIn this issue we continue to publish past Alan Kay articles. This month we feature two more of his famous articles.Global Village or Global Civilization? by Alan C. KayRevealing the Elephant: The Use and Misuse of Computers in Education by Alan C. KayThe Rolodex Tutorial by John HinsleyHere at last John Hinsley's Rolodex Tutorial in pure Squeak!SUnit Explained by Stephane DucasseA clear and detailed explanation of the SUnit framework useful not only for using the framework but also discusses the issues related to the imporatnce and practicability of testing using SUnit.Squeak User Manual by Maarten MaartenszMaarten has a real hard go at the elusive goal of documenting Squeak. His user manual is a very concrete definition of Squeak. We will publish the continuation of his efforts as well.Squeak Tweaks: Are we Still Editing HTML? by Bijan ParsiaThe short answer is, yes!Squeak for Beginners: A Mini tour of Squeak's ClassesEnjoy some of Squeak's most used classes with some insider informationSqueak News Exclusive Interview with Kim Rose: Part 2A Mini Utility: Auto Save MorphSeason's Greetings! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyg at leastfixedpoint.com Mon Aug 3 07:17:54 2020 From: tonyg at leastfixedpoint.com (Tony Garnock-Jones) Date: Mon, 3 Aug 2020 09:17:54 +0200 Subject: [squeak-dev] Squeak News from 2001 In-Reply-To: References: Message-ID: <78401217-5fa9-a84f-94fe-dbda89cc610a@leastfixedpoint.com> This is wonderful, Vanessa! Thank you very much! (I'm particularly delighted to see Ted Kaehler's "A Most Unusual Method Finder" article; it'll be something I can point people toward next time they ask for a reference.) Regards, Tony On 8/3/20 3:47 AM, Vanessa Freudenberg wrote: > Hi all, > > Squeak News was a multimedia e-zine published by Tansel Ersavas in 2001 > as Squeak images on CD-ROM. Each issue contains contributions from many > people in our community. I build a web viewer using SqueakJS: > https://smalltalkzoo.computerhistory.org/SqueakNews/index.html > > The source code is on GitHub: > https://github.com/squeak-smalltalk/squeaknews > Contributions welcome! > > If you find something that doesn't work correctly, please file a bug > report on github. > > Enjoy! > Vanessa > > I'm copying the table of contents below: > > > Volume 1 Issue 1, July 2001 > > > Open Issue #1 > > > Cover Page > Did you have fun with our cover page? We certainly did. A little > heavy with animation, a little slow on slower machines, but still > enjoyable. So if at any point you would like to return to it please > feel free. > Our First Issue > What On Earth Are We Doing? by Tansel Ersavas > Well, now you know. Read all about it in this editorial note. > This month in the Squeak World by Bijan Parsia > This month's news include summaries of the activity of the Squeak > list and the Squeak foundation list. Squeak in the press and Squeak > Central's new move is high on the agenda. > Mini E-View with Dan Ingalls > Do not miss this mini E-view with Dan Ingalls about the latest move > of Squeak Central and future of Squeak! > A Most Unusual Method Finder by Ted Kaehler > In this essay Ted takes us through the Method finder and the idea > behind it. Ted explains how he started writing the method finder, > how it works, how the symbol table is searched, how "methods by > example" works and how method finder handles an exhaustive search > without causing any damage to the system. > Interview with John Maloney > Part 1: Before Apple > In the first part of this in-depth interview, we talked with John > about the early days: how he started working with Smalltalk, his > early Xerox days, the origins of Celeste, his experience with other > systems, constraint based programming, Self and the birth of Morphic. > VMMaker - a tool to make VM making simpler by Tim Rowledge > In this article, Tim explains the VmMaker and the motive behind it. > Tim's VmMaker makes the process of generating VMs much easier. Tim > explains the usage of VmMaker and he states possible enhancements to it. > The Foundations of SqueakNOS by the SqueakNOS team / Luciano Notarfrancesco > SqueakNOS is an ambitious project that aims to strip that useless > huge nappy padded underwear of computers that is called an > "operating system" and replace it with a layer all written in > Squeak! Here the SqueakNOS team explain how they intend to do it, > what they have done so far, how they have done it, and what they aim > to do. > Squeak Tweaks: Celeste as a Mailing List Summarizer by Bijan Parsia > In this corner of the e-zine, Bijan will show us how to tweak Squeak > with interesting insights. > In his first article Bijan takes Celeste and turns it into a mail > list summarizer! He explains the need for the mail summarizer (after > all he volunteered for the Squeak News monthly email summaries!) and > step by step explains how Celeste is turned into a handy mail > summarizer sidekick. After reading this article you will have a good > idea about how he can categorize and sift through the enormous > amount of email that Squeak list generates with a little help from > his new Celeste-MLS! > Squeak Documentation Initiative > Squeak Documentation initiative is a Squeak News sponsored activity > that will start with this issue. Here we will explain mechanisms and > ask for volunteers for this initiative. The goal is to create a > giant living reference manual and a reference server that any Squeak > that is on the net can hook up to and access to on-line > documantaion. This documentation will be in a form that can be > embedded in any image and will have built in mechanisms to update > itself when changes are made and post these updates to a central > server or other peers. Another useful document is a user guide which > will also be semi-automatically generated. Documentation swiki pages > will be used to capture most additions and modifications to the > documentation. More details will soon be available from the Squeak > News site. > Fun with Squeak: Learn to Juggle with Squeak by Tansel Ersavas > In this article Tansel takes you to a journey that will juggle two > things at once: learning juggling while writing a tutorial that > teaches juggling. It is a meta-juggling tutorial that is a lot of > fun. Most aspects of juggling from choosing the right balls to how > not to juggle with raw eggs are clearly illustrated with animated > examples > Squeak Notebook by Torsten Bergmann > A little example of how a SqueakBook can look like a notebook > Best of Bob's SuperSwiki: Squeak or How the Mouse Roars > Each month we will feature a project published in Bob's super Swiki > or other public Super Swikis. This month we feature the first part > of Torsten Bergman's HTMR: Squeak or How the Mouse Roars' series. > Squeak Graphics by Ali Chamas > Graphics created by Ali Chamas using Squeak captured the attention > of many people and some of these graphics were featured in web sites > such as flipcode.com . See them yourself. > This Month's Quiz: Detecting an Alarm via Email from a Remote Location > Tributes: Pat Caudill and Jerry Archibald > This month we have lost 2 Smalltalkers. Pat Caudill (1945-2001) > passed away June 14, 2001, and Jerry Archibald (1940-2001) passed > away June 22, 2001. > > All Issues > > > > Volume 1 Issue 2, 15 August 2001 > > > Open Issue #2 > > > Focus on Beginners > Starting with this issue we will focus on beginners and every issue > of Squeak News will feature at least one article targeted at > beginners. This month we feature two articles that would help > beginners. You will also find in this issue very interesting > articles about hardware that can run Squeak, a very interesting user > interface framework for UI development specifically tailored towards > PDAs and Kiosk style applications. The Squeak Tweaks corner will > feature a quickie HTML editor. For the diehards who are determined > to rip the operating system under Squeak the current installment of > the SqueakNOS series is "Story of the Quake Packet". You will also > find the conclusion of the Juggling article and continuation of our > in-depth interview with John Maloney. > Squeak Related News > This month's news include summaries of the activity of the Squeak > list and the Squeak foundation list and our report on fun new > hardware to play with Squeak > Monthly digest of the Squeak Mailing list by Bijan Parsia > Every month Bijan summarizes the Squeak mailing list painstakingly > by organizing postings under threads with commentary using home-bred > tools that he developed. (and explained some of them in the July > issue) If you are busy and can't follow the fast pace of the Squeak > list this is the column to read! This section will be emailed to our > email subscribers as well as posted on the on the web. > Mean Squeak Machines > In these articles we chase our DynaBook dreams and look at some of > the latest systems from super PDAs to desktop units that can run > Squeak happily. > Cool Peripherals > We also investigate some peripherals that can enhance our Squeak > experience from tablet-screens to solid-state USB disk units that > are attached to key-rings. > How to Begin Squeak by Tansel Ersavas > This article is the first of a series about Squeak that aims to take > a person from the beginner stage to the level of a highly > sophisticated programmer during the course of this (long) series. In > this article, Tansel outlines basic concepts of object oriented > approach and Squeak. He emphasizes differences between Squeak and > most other languages, explains why it is harder for people who have > been exposed to other languages to learn Squeak and suggests > strategies that would accelerate the learning process. > An Approach for Teaching and Learning Squeak by Michael Guenter > Michael brings us the experience of a teacher and proposes an > approach for learning and teaching Squeak. He defines different > kinds of newbies and discusses best approach for them and elaborates > on his "study buddies" idea which has already attracted interest. > Control your Submorphs by Ted Kaehler and Andreas Raab > In this active article Ted and Andreas take us to a tour of the new > layout mechanism of morphs recently introduced to Squeak by Andreas > Raab. As nicely stated by Ted: "Why talk about something when you > can see it in action", this article will come to life when playing > with it very true to the soul of Squeak News. > The second part of an In-depth Interview with John Maloney > In the second part of this in-depth interview, John talks about the > Apple days, the birth of Squeak, how Squeak became on open source > project, and how his expectations were exceeded with community > support. We also discussed with him about the past life of Morphic > before Squeakt. > A Minimal User Interface Toolkit for PDAs and Kiosks by Tansel Ersavas > In this article Tansel introduces us to a very basic set of tools > that help us implement simple user interfaces especially suitable > for point and click applications. These applications are more likely > to be useful on environments where using Morphic is not feasible > such as small PDAs and Kiosk applications that operate on hardware > with limited resources and where the input is limited to a touch > screen or stylus input. > Story of a Quake Packet by the SqueakNOS team > Do you know what these naughty people at the SqueakNOS team do when > their workmates go into a frenzy of playing Quake? They peep the > network activity using nothing other than their naughtier > collaborator Squeak! Read this captivating story of intrigue and > deception, and find out all about those Quake packets that lurk at > your network pipes while people are playing Quake!. > Squeak Tweaks: A Quickie HTML Editor by Bijan Parsia > In this corner of the e-zine, Bijan shows us how to tweak Squeak > with interesting insights. > In this article Bijan has a go at a quickly put together HTML editor > which could be the beginning of a HTML editor liberator! > Juggle with Squeak by Tansel Ersavas > In this part of this series Tansel finally puts his act together > (almost), both about juggling, and finishing this tutorial, and the > rest of the people can finally juggle. He still has to write about > the beautification process though. > Squeak Documentation initiative > Squeak Documentation initiative is a Squeak News sponsored activity > that will continue with this issue. This month's initiative will be > discussed on our documentation SWiki later when the documentation > SWiki is up and running. > Squeak quiz with surprize rewards > Every month, we have a question that addresses a specific problem > and collect all answers. We will then publish selected answers and > declare one as the "editor's choice". The person who sent the > selected solution will receive a mystery reward from us. > > All Issues > > > > Volume 1 Issue 3, 15 September 2001 > > > Open Issue #3 > > > Squeak for a Better World! > We changed our theme to Squeak for a Better World after the tragic > events of September 11. Read all about the shock, frustrations and > ideas about Squeak for a better world. > Focus: Multimedia > There is a lot in Squeak News this month. Close to the end of this > month is the 5th anniversary of the day Squeak was placed on the > Internet for the rest of the world to enjoy and we e-talked with Dan > Ingalls about this most important event. The focus of this issue is > Squeak and Multimedia and we have a significant amount of content > about the subject. We feature two interactive demos: Squeak Cinema: > A demo of the Squeak MPEG player, and SqueakAmp: The Squeak MP3 > player. In addition we feature an article about the MPEG player of > Squeak by John McIntosh, the full set of the active essays on > studying computer music by Mark Guzdial and an article about > PhotoSqueak by Juan Manuel Vuletich. Karl Ramberg's contribution is > a short active essay about Art and Computers. Our beginners series > focus is objects, messages and beyond. An example of system level > programming in Squeak is given in the article "The SqueakNOS > keyboard". We also solicited an article about one of the recent > developments about Squeak GemStone connectivity and we are happy to > feature this article about GemSqueak. > Squeak Related News > This month's news include an E-view with Dan Ingalls, summaries of > the activity of the Squeak list and John McIntosh' Essen STUG reports. > Squeak's 5th Birthday! An e-view with Dan Ingalls > After looking at all the evidence we decided that the 25th September > 1996 was the day Squeak was unleashed to us mortals (incidentally > after about 9 months of incubation)! We declared this day to be > Squeak's "birth" day. We asked Dan about that day, a little earlier, > and a little later, and Dan answered! > Monthly digest of the Squeak Mailing list by Bijan Parsia > Every month Bijan summarizes the Squeak mailing list painstakingly > by organizing postings under threads with commentary using home-bred > tools that he developed. (and explained some of them in the July > issue) If you are busy and can't follow the fast pace of the Squeak > list this is the column to read! This section will be emailed to our > email subscribers as well as posted on the on the web. > The World of Squeak: Objects, Messages and Beyond by Tansel Ersavas > This article is the second installment of a series about Squeak that > aims to take a person from the beginner stage to the level of a > highly sophisticated programmer during the course of this (long) > series. In this article, Tansel explains the basic concepts of > Squeak such as objects, messages and relationships between objects. > Active Essays for Studying Computer Music by Mark Guzdial > If Mark Guzdial isn't an institution, he should be made into one. > Author/instigator/editor of the two current Squeak books, hacker of > PWS & the original Swiki, hoster of Swikis, teacher of Squeak... He, > his students, and his classes are always throwing out cool stuff for > the rest of us. For his class on "Computer Music Implementation", he > wrote a series of active essays, which cover everything from the > built in Squeak sound tools to MIDI. Aside from being nicely > written/constructed on interesting topics -- i.e., an enjoyable read > -- they are great examples of active essays. Mark was kind enough to > let us feature the entire series in Squeak News with a bonus > introduction that puts these great active essays in perspective. > MPEG: Finding a Fit by John McIntosh > Among all these activities that keeps us all informed about what is > going on around the world, John found the time to write about that > magical plug-in that enables us to play highly compressed video and > from within the comforts of Squeak. > Squeak Cinema > A showcase of the MPEG player and some of Squeak's presentation > abilities. It features a trailer of a movie to be released next year > by 20th Century Fox (C) 20th. Century Fox. The main feature is named > "The Killer Bean Part 2, The Party" short masterpiece by Jeff Lew, > slighltly over 6 minutes. This is an animation fully done by the > author himself in 3 years on one computer. After the movie was > released on the net it was downloaded more than 1 million times and > helped him to join to the ranks of Hollywood's magic makers and he > has been involved in movies such as the Matrix and the Matrix 2. We > wish to advise our audiance that the movie contains strong violance > and people who can't watch coffee beans destroyed should refrain > from watching the movie. Sorry? What? No we don't have any grudges > against coffee in any shape and we haven't hired the killer bean for > any jobs. > SqueakAmp: Squeak's MP3 player > A demonstration of the MP3 playback ability of Squeak that is > written by Bob Hartwig using the MPEG plug-in. > Art, Computers by Karl Ramberg > Karl tosses questions about Art and Computers and starts > experimenting in this short and sweet active essay... > The Conclusion of our In-depth Interview with John Maloney > In the conclusion of this in-depth interview, we talked with John > about Morphic, how it differed from the original Self Morphic, and > what is in the crystal ball for Morphic. We also talked about the > Disney days, some projects that John got involved and more... > The Squeak Keyboard: An Introduction to Low Level Programming in > SqueakNOS by the SqueakNOS team > This article explains how Squeak handles keyboard programming from > within SqueakNOS. Don't try this code at home! It will only work > within SqueakNOS. > PhotoSqueak: An Image Processing Framework by Juan Manuel Vuletich > What started as a school project may well turn out to be a powerful > general purpose digital image processing system for Squeak. Learn > all about it. > GemSqueak: A Full Functional GemStone Client by Valeria Murgia > GemSqueak is a full featured and full functional GemStone client. > Valeria Murgia with collaboration by Leandro Caniglia explains this > exciting project. Keep an eye for their SqueakAttic OODB project as > well. > Book Summary: Squeak's First Book and Multimedia > This is the first book summary published in Squeak News and > naturally it is about the first book on Squeak ever published. > Globe by Torsten Bergmann > A cool demo of 3D on a background created by the author. > Juggle with Squeak by Tansel Ersavas > In this part of the series Tansel beautifies the Juggling Scene and > explains how to create a simple user interface for the Juggling demo. > Squeak quiz with surprize rewards > This month we will not have a Squeak quiz, instead we are preparing > a Squeak Challenge > > All Issues > > > > Volume 1 Issue 4, 15 October 2001 > > > Open Issue #4 > > > > /Powerful Ideas in the Classroom/ > > Editor's Note > Monthly News: > This month's news include summaries of the activity of the Squeak > list and John McIntosh's OOPSLA trip reports. > Monthly digest of the Squeak Mailing list by Bijan Parsia > Every month Bijan summarizes the Squeak mailing list painstakingly > by organizing postings under threads with commentary using home-bred > tools that he developed. (and explained some of them in the July > issue) If you are busy and can't follow the fast pace of the Squeak > list this is the column to read! This section will be emailed to our > email subscribers as well as posted on the on the web. > OOPSLA Trip Reports by John McIntosh > John is an avid follower and documenter of almost every event. We > asked if he would allow his excellent OOPSLA trip reports that are > published on his site to be included in Squeak News and he kindly > allowed us to include them with the Squeak News e-zine. Once we > merged these reports with pictures of Michael Rueger it turned out > to be a lively digest, just like if you were there! > Features > Stronger Goals for Education by Alan Kay > In this article Alan defines stronger goals for education and > explains the role of Squeak in this picture. A must read for all > parties who have an interest in education. > Treasures Unearthed: Alan Kay's Active Essays and Articles > We used this opportunity to feature many of Alan's past articles and > active essays. As always Alan was very generous in allowing us to > reprint these immense treasures in our colorful format and we have > tried to illustrate them a little as well. > Authoring by Alan Kay > This is the introduction published on SqueakLand.org. It is a short > but a very powerful article summarizes the purpose and the origin of > Squeak > EToys and SimStories in Squeak by Alan Kay > This is a well known active essay by Alan Kay also featured on > SqueakLand.org. In this active essay Alan shows us how simple > scripting can be used to explain ideas that can't easily be > explained. It explains the power of the Etoy system, the concept of > active essays, why Etoys are important to science and math, and how > Etoys are envisioned to be used in such active essays to even > encyclopedias. A must read and should be in the pockets of every > trainer! > Computers, Networks and Education by Alan Kay > In this classic originally printed in Scientific American in > September 1991 issue Alan > Science Already IS Art! by Alan Kay > A short and sweet article originally written for The San Jose Museum > of Technology brochure. > We will also publish more of Alan Kay's articles next month > Squeak in the Open Charter School by B.J. Allen-Conn > B.J. has been involved in teaching children about interactive > computing environments since 1986. Benefit from her experience in > teaching Squeak to children. There are several examples of students > of the Open Charter School. Be sure to check them all. > The Big Race! by Open Charter School students > Don't miss this Grand Prix of cars developed by students racing to > capture the elusive championships. The creativity of students shine > when cars of all colors and shapes take on each other at the track! > Interactive Web-based Modeling and Explorations by Naala Brewer > In this article Naala details her interactive web-based explorations > with students during the course of her teaching of interactivity > through Squeak. > Etoy examples by various students > Cool examples of ingenious usage of Squeak Etoy system by students > in 4th and 5th grades in the Open Charter School. Be inspired by > their creativity! > School Squeaking by Cathleen Galas > Cathleen teaches at the Seeds University Elementary School, which is > the laboratory school for the Graduate School of Education and > Information Studies, UCLA. As a teacher already experienced in > introducing kids to the Microworlds logo she details her experience > with Squeak and Squeak's advantages over other systems. Her > illuminating observations and student feedback make an excellent > case for Squeak's use in the classroom. > Youngest Users of Squeak Speak > Feedback by some of the youngest users of Squeak > Etoys: Squeak as an Authoring System for Kids (and Kids at Heart!!) > We feature every tutorial we can find about the Etoy system by > various authors. Enjoy them all! > Squeak News Exclusive Interview with Kim Rose > This month we had a chance to talk to Kim Rose (co-Director of the > Viewpoints Research Institute: now home of Squeak Central, long term > member of the Squeak Central, co-editor of the book Squeak: Open > Personal Computing and Multimedia) in depth about how she got > involved in computing and Squeak, media and cognitive science, her > interest and efforts in Squeak and kids, Apple days, Disney days, > and post Disney. This month we will publish Part 1 of this 3 part > series. > Plugging in Squeak by Michael Rueger > In this article Michael takes us from the beginning and tells us how > the Squeak plug-in came to life, where was it first used, how is it > used and what is and what is not in the pipeline. > As a courtesy to our subscribers we include the plug-in installers > for various platforms for you to save you some download time. > From objects to classes by Tansel Ersavas > This article is the third installment of a series about Squeak that > aims to take a person from the beginner stage to the level of a > highly sophisticated programmer during the course of this (long) > series. In this article, Tansel explains the concept of a class, how > classes and objects are related, and how classes are related to each > other. > A Minimal Multimedia Manager for PDAs and Kiosks by Tansel Ersavas > This article will be published on our SWiki later due to heavy > commitments and health problems of the author. We apologize. > Juggle with Squeak by Tansel Ersavas > In this part of the series Tansel finishes the demo and packages it > with a gift wrap! > Little Butterfly > A little poem by a very sweet girl! > Squeak's Most Wanted List > Starting this issue we will create a "Most Wanted list" for Squeak > and offer some rewards. Since it will be on an SWiki page you are > free to add your "most wanted feature or function" to the list. In > every issue of Squeak we will recite the top of the list, newcomers > to this list and report progress if any. This month there is a grand > challenge: Target:Advance > > All Issues > > > > Volume 1 Issue 5, November 2001 > > > Open Issue #5 > > > > /Future Technologies that may impact Squeak/ > > Editorial > The Squeak Mailing List Summary > Actually, this month it is not a summary, but an entire dump of all > the mails in the mailing list. > Future Technologies that may Impact Squeak by Tansel Ersavas > In this issue of Squeak News we decided to have a quick trip to the > near future and come back with some gossip about what might impact > Squeak and in what ways. > Mean Squeak Machines: Futuristic Toys > Continuing our future theme is the seciton on mean Squeak machines: > Futuristic toys. Enjoy them! > A Simple Task Management Tool by Tansel Ersavas > This article introducs a simple task management tool which could be > used as a simple project management tool as well as a task > scheduling tool. > Alan Kay Treasure Chest > In this issue we continue to publish past Alan Kay articles. This > month we feature two more of his famous articles. > Global Village or Global Civilization? by Alan C. Kay > Revealing the Elephant: The Use and Misuse of Computers in Education by > Alan C. Kay > The Rolodex Tutorial by John Hinsley > Here at last John Hinsley's Rolodex Tutorial in pure Squeak! > SUnit Explained by Stephane Ducasse > A clear and detailed explanation of the SUnit framework useful not > only for using the framework but also discusses the issues related > to the imporatnce and practicability of testing using SUnit. > Squeak User Manual by Maarten Maartensz > Maarten has a real hard go at the elusive goal of documenting > Squeak. His user manual is a very concrete definition of Squeak. We > will publish the continuation of his efforts as well. > Squeak Tweaks: Are we Still Editing HTML? by Bijan Parsia > The short answer is, yes! > Squeak for Beginners: A Mini tour of Squeak's Classes > Enjoy some of Squeak's most used classes with some insider information > Squeak News Exclusive Interview with Kim Rose: Part 2 > A Mini Utility: Auto Save Morph > Season's Greetings! > > > From marcel.taeumel at hpi.de Mon Aug 3 08:13:55 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 3 Aug 2020 10:13:55 +0200 Subject: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> Message-ID: Hi all! I think that Tom (tobe) had the idea to publish bootstrap MCZs via Metacello's GitHub releases page since it is very easy to point Monti(!)cello to such an HTML page to fetch downloadable content. Best, Marcel Am 02.08.2020 22:13:18 schrieb Jakob Reschke : Probably related thread: http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev : > > Hi folks, > > This probably holds for 5.3 install too. > > In the preferences wizard, the extras stuff, the Install Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" > > iirc, from the pharo discord, SmalltalkHub is going away. > > You will probably need a different repo. > > cordially, > > tty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Aug 3 08:21:57 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 3 Aug 2020 10:21:57 +0200 Subject: [squeak-dev] [Proposed] include PromisesLocal in trunk In-Reply-To: <99b4ede5-9716-c646-8c9a-dbe9b6885a89@pm.me> References: <7c8ad646-d5c3-9da8-93fc-0ef6be932163@pm.me> <265e61a3-00a4-ee10-eb88-3c3741418cb7@pm.me> <99b4ede5-9716-c646-8c9a-dbe9b6885a89@pm.me> Message-ID: Hi all! I like the idea of fixing Squeak's implementation of promises. However, I am -1 for adding PromiseLocal/PromiseRemote but would rather like to sse am implementation of Promise that works for both cases. Also, "PromiseERefs" and "BrokenERefs" sounds too cryptic. We can find better names here. :-) Best, Marcel Am 02.08.2020 15:48:49 schrieb Robert Withers via Squeak-dev : Hello, there, In reading the chapter on Promises, in the section on the E programming language, of which PromisesLocal is modeled, the following needs clarification: Subsequent messages can also be eventually sent to a promise before it is resolved. In this case, these messages are queued up and forwarded once the promise is resolved. The messages are not queued up at the local promise, pending forwarding to the eventual result; they are forwarded to a promise, local to the computation. This is mainly important once you have introduced remote promises (PromisesRemote). Messages are sent to the computation and they queue up local, for execution upon the eventual value, #whenMoreResolved:. K, r NB: here is a chained message sending eventually, with Promises. ((10 eventual factorial / 100) * 25)     whenResolved: [:i | i value]. On 8/2/20 8:55 AM, Robert Withers wrote: Hi all'y'all! Here is a textbook on Promises, for your understanding. [Inspired by functional programming, one of the major distinctions between different interpretations of this construct have to do with pipelineing or composition. Some of the more popular interpretations of futures/promises make it possible to chain operations, or define a pipeline of operations to be invoked upon completion of the computation represented by the future/promise. This is in contrast to callback-heavy or more imperative direct blocking approaches.] http://dist-prog-book.com/chapter/2/futures.html [http://dist-prog-book.com/chapter/2/futures.html] K, r On 8/1/20 12:09 PM, Robert Withers wrote: Good afternoon! I wish to offer a proposal for discussion to include PromisesLocal into trunk and to replace the implementation of Promise/BrokenPromise with PromiseERefs and BrokenERefs. The underlying concurrency model has explicit use of an event loop in PromisesLocal. The code size is minimal but adds the Promises/A+ specification to Squeak, that can be extended into a remote reference solution and an Agent communications architecture. Exceptions are processed. I want to define a VatSemaphore that allows the user to #wait/#signal, and they get 'immediate' control flow which most folks find as a valid way to describe steps taken.Under the covers the VatSemaphore is connected to the Vat, as an element in a forthcoming continuationPool. So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the continuation is captured and placed in the pool and the vat's event loop continues with the next event. When #signal is sent to this VatSemaphore, the continuation is scheduled: in the queue and removed from the pool. The event loop will process the continuation. On 7/28/20 3:41 PM, Jakob Reschke wrote: My other suspicion is that we would nevertheless need an extended debugger to deal well with such eventual control flow. A debugger with a "step to resolution" or so that steps to the point where the messages are eventually answered, or the receiver even activated. I think that this is a great idea! Research in this direction would be AWESOME! On 8/1/20 11:39 AM, Robert Withers wrote: On 7/28/20 3:41 PM, Jakob Reschke wrote: Current Kernel Promises are also not good at that without sprinkling breakpoints... This and the dreadful error handling ("well so I forgot the block argument for the callback again and got an error from value:, now how do I find out in the debugger which method even contains my wrong block?!?" What if the debugger could allow you to browse reactor creation methods? Where is the closure created? I can imagine an implementation of EIO (http://wiki.erights.org/wiki/EIO_Redesign [http://wiki.erights.org/wiki/EIO_Redesign]), Eventual I/O, that has a #whenAvailable: semantic. Then the UI event loop is just an EInputStream and we could flip the entire system over to using a promise architecture. Kindly, rabbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Aug 3 08:30:06 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 3 Aug 2020 10:30:06 +0200 Subject: [squeak-dev] Tab-key navigation in dialogs/windows Message-ID: Hi all! > A related topic might be the absence of tab navigation in Squeak. In many GUI systems there is a key to move the focus to the next widget, mostly the tab key. There is no such thing in Squeak, is it? It's not working. But here are code fragments: Morph >> #tabAmongFields Morph >> #tabHitWithEvents: Also browse senders of both. If I would implement it, I would do it as an event filter but only for Pluggable*Morph classes. The tool builder can then install those filters after building the widgets. Note that there is #keyboardFocusDelegate, which configures calls to HandMorph >> #newKeyboardFocus:. There is also #hasKeyboardFocus:. Best, Marcel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Mon Aug 3 10:49:47 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Mon, 3 Aug 2020 12:49:47 +0200 Subject: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> Message-ID: <7F78D9C3-85B3-4514-B85B-9A010EF6B88F@gmx.de> > On 03.08.2020, at 10:13, Marcel Taeumel wrote: > > Hi all! > > I think that Tom (tobe) had the idea to publish bootstrap MCZs via Metacello's GitHub releases page since it is very easy to point Monti(!)cello to such an HTML page to fetch downloadable content. In that case, we can put them on files.squeak.org, too … -t > > Best, > Marcel >> Am 02.08.2020 22:13:18 schrieb Jakob Reschke : >> >> Probably related thread: >> http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html >> >> Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev >> : >> > >> > Hi folks, >> > >> > This probably holds for 5.3 install too. >> > >> > In the preferences wizard, the extras stuff, the Install Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" >> > >> > iirc, from the pharo discord, SmalltalkHub is going away. >> > >> > You will probably need a different repo. >> > >> > cordially, >> > >> > tty >> > >> > >> > From robert.withers at pm.me Mon Aug 3 10:55:12 2020 From: robert.withers at pm.me (Robert Withers) Date: Mon, 03 Aug 2020 10:55:12 +0000 Subject: [squeak-dev] [Proposed] include PromisesLocal in trunk In-Reply-To: References: <7c8ad646-d5c3-9da8-93fc-0ef6be932163@pm.me> <265e61a3-00a4-ee10-eb88-3c3741418cb7@pm.me> <99b4ede5-9716-c646-8c9a-dbe9b6885a89@pm.me> Message-ID: <8a298436-0538-efd1-6c81-b1788f00df6f@pm.me> Hi Marcel, Why are you -1 with PromisesLocal? It is easy to add the protocol published by the current Promise class, minus the wait protocols. I can certainly rename the proxies, as well. So what specifically are you -1 abut wrt PromisesLocal? PromisesRemote is in addition to PromisesLocal, it extends several remote proxies. K, r On 8/3/20 4:21 AM, Marcel Taeumel wrote: > Hi all! > > I like the idea of fixing Squeak's implementation of promises. However, I am -1 for adding PromiseLocal/PromiseRemote but would rather like to sse am implementation of Promise that works for both cases. Also, "PromiseERefs" and "BrokenERefs" sounds too cryptic. We can find better names here. :-) > > Best, > Marcel > >> Am 02.08.2020 15:48:49 schrieb Robert Withers via Squeak-dev [](mailto:squeak-dev at lists.squeakfoundation.org): >> >> Hello, there, >> >> In reading the chapter on Promises, in the section on the E programming language, of which PromisesLocal is modeled, the following needs clarification: >> >>> Subsequent messages can also be eventually sent to a promise before it is resolved. In this case, these messages are queued up and forwarded once the promise is resolved. >> >> The messages are not queued up at the local promise, pending forwarding to the eventual result; they are forwarded to a promise, local to the computation. This is mainly important once you have introduced remote promises (PromisesRemote). Messages are sent to the computation and they queue up local, for execution upon the eventual value, #whenMoreResolved:. >> >> K, r >> >> NB: here is a chained message sending eventually, with Promises. >> >>> ((10 eventual factorial / 100) * 25) >>> whenResolved: [:i | i value]. >> >> On 8/2/20 8:55 AM, Robert Withers wrote: >> >>> Hi all'y'all! >>> >>> Here is a textbook on Promises, for your understanding. >>> >>>> [Inspired by functional programming, one of the major distinctions between different interpretations of this construct have to do with pipelineing or composition. Some of the more popular interpretations of futures/promises make it possible to chain operations, or define a pipeline of operations to be invoked upon completion of the computation represented by the future/promise. This is in contrast to callback-heavy or more imperative direct blocking approaches.] >>> >>> http://dist-prog-book.com/chapter/2/futures.html >>> K, r >>> >>> On 8/1/20 12:09 PM, Robert Withers wrote: >>> >>>> Good afternoon! >>>> >>>> I wish to offer a proposal for discussion to include PromisesLocal into >>>> trunk and to replace the implementation of Promise/BrokenPromise with >>>> PromiseERefs and BrokenERefs. The underlying concurrency model has >>>> explicit use of an event loop in PromisesLocal. The code size is minimal >>>> but adds the Promises/A+ specification to Squeak, that can be extended >>>> into a remote reference solution and an Agent communications >>>> architecture. Exceptions are processed. >>>> >>>> I want to define a VatSemaphore that allows the user to #wait/#signal, >>>> and they get 'immediate' control flow which most folks find as a valid >>>> way to describe steps taken.Under the covers the VatSemaphore is >>>> connected to the Vat, as an element in a forthcoming continuationPool. >>>> So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the >>>> continuation is captured and placed in the pool and the vat's event loop >>>> continues with the next event. When #signal is sent to this >>>> VatSemaphore, the continuation is scheduled: in the queue and removed >>>> from the pool. The event loop will process the continuation. >>>> >>>>>> On 7/28/20 3:41 PM, Jakob Reschke wrote: >>>>>> My other suspicion is that we would nevertheless need an extended >>>>>> debugger to deal well with such eventual control flow. A debugger >>>>>> with a "step to resolution" or so that steps to the point where the >>>>>> messages are eventually answered, or the receiver even activated. >>>>> >>>>> I think that this is a great idea! >>>> >>>> Research in this direction would be AWESOME! >>>> >>>> On 8/1/20 11:39 AM, Robert Withers wrote: >>>> >>>>>> On 7/28/20 3:41 PM, Jakob Reschke wrote: >>>>>> Current Kernel Promises are also not good at that without sprinkling >>>>>> breakpoints... This and the dreadful error handling ("well so I >>>>>> forgot the block argument for the callback again and got an error >>>>>> from value:, now how do I find out in the debugger which method even >>>>>> contains my wrong block?!?" >>>>> >>>>> What if the debugger could allow you to browse reactor creation >>>>> methods? Where is the closure created? >>>> >>>> I can imagine an implementation of EIO >>>> ( >>>> http://wiki.erights.org/wiki/EIO_Redesign >>>> ), Eventual I/O, that has a >>>> #whenAvailable: semantic. Then the UI event loop is just an EInputStream >>>> and we could flip the entire system over to using a promise architecture. >>>> >>>> Kindly, >>>> rabbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Mon Aug 3 11:55:48 2020 From: gettimothy at zoho.com (gettimothy) Date: Mon, 03 Aug 2020 07:55:48 -0400 Subject: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <7F78D9C3-85B3-4514-B85B-9A010EF6B88F@gmx.de> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <7F78D9C3-85B3-4514-B85B-9A010EF6B88F@gmx.de> Message-ID: <173b42d84b7.c5e3ac7552071.3797801497954478016@zoho.com> Thanks all Are there steps I should be taking to help facilitate this? Thx ---- On Mon, 03 Aug 2020 06:49:47 -0400 Das.Linux at gmx.de wrote ---- > On 03.08.2020, at 10:13, Marcel Taeumel wrote: > > Hi all! > > I think that Tom (tobe) had the idea to publish bootstrap MCZs via Metacello's GitHub releases page since it is very easy to point Monti(!)cello to such an HTML page to fetch downloadable content. In that case, we can put them on files.squeak.org, too … -t > > Best, > Marcel >> Am 02.08.2020 22:13:18 schrieb Jakob Reschke : >> >> Probably related thread: >> http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html >> >> Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev >> : >> > >> > Hi folks, >> > >> > This probably holds for 5.3 install too. >> > >> > In the preferences wizard, the extras stuff, the Install Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" >> > >> > iirc, from the pharo discord, SmalltalkHub is going away. >> > >> > You will probably need a different repo. >> > >> > cordially, >> > >> > tty >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at usmedrec.com Mon Aug 3 13:00:19 2020 From: ron at usmedrec.com (Ron Teitelbaum) Date: Mon, 3 Aug 2020 09:00:19 -0400 Subject: [squeak-dev] Tab-key navigation in dialogs/windows In-Reply-To: References: Message-ID: Hi All, We created a class CUserInterface and subclassed all of our forms from there and did the following. Widgets have tabStop (should tab stop here) and tabOrder, they respond to hasTabFocus: and implement onTabFocus and onTabExit, which basically add or remove highlights the field, sents the keyboard focus, (and tells the screen reader for blind users to read the field name). CUserInterface >> onTab | allElements selectedElement i | allElements := SortedCollection sortBlock: [:a :b | a tabOrder < b tabOrder]. self allElementsDo: [:a | (a tabStop and: [a tabOrder > -1]) ifTrue: [ allElements add: a ]. ]. i := 0. selectedElement := allElements detect: [:a | i := i + 1. a hasTabFocus = true] ifNone: [nil]. selectedElement ifNotNil: [:a | a hasTabFocus: false]. (allElements at: (i+1) ifAbsent: [allElements first]) hasTabFocus: true. There is also a onShiftTab to go backwards. onShiftTab | allElements selectedElement i | allElements := SortedCollection sortBlock: [:a :b | a tabOrder < b tabOrder]. self allElementsDo: [:a | (a tabStop and: [a tabOrder > -1]) ifTrue: [ allElements add: a ]. ]. i := 0. selectedElement := allElements detect: [:a | i := i + 1. a hasTabFocus = true] ifNone: [nil]. selectedElement ifNotNil: [:a | a hasTabFocus: false]. (allElements at: (i-1) ifAbsent: [allElements last]) hasTabFocus: true. All the best, Ron Teitelbaum On Mon, Aug 3, 2020 at 4:30 AM Marcel Taeumel wrote: > Hi all! > > > A related topic might be the absence of tab navigation in Squeak. In > many GUI systems there is a key to move the focus to the next widget, > mostly the tab key. There is no such thing in Squeak, is it? > > It's not working. But here are code fragments: > > Morph >> #tabAmongFields > Morph >> #tabHitWithEvents: > > Also browse senders of both. > > If I would implement it, I would do it as an event filter but only for > Pluggable*Morph classes. The tool builder can then install those filters > after building the widgets. Note that there is #keyboardFocusDelegate, > which configures calls to HandMorph >> #newKeyboardFocus:. There is also > #hasKeyboardFocus:. > > Best, > Marcel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Mon Aug 3 14:41:53 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 03 Aug 2020 14:41:53 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1781 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f28223087e36_13fed8471981c20219b@travis-tasks-5fff5ccccd-8b4c4.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1781 Status: Errored Duration: 17 mins and 29 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/714488562?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Mon Aug 3 14:48:05 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 3 Aug 2020 16:48:05 +0200 Subject: [squeak-dev] [Proposed] include PromisesLocal in trunk In-Reply-To: <8a298436-0538-efd1-6c81-b1788f00df6f@pm.me> References: <7c8ad646-d5c3-9da8-93fc-0ef6be932163@pm.me> <265e61a3-00a4-ee10-eb88-3c3741418cb7@pm.me> <99b4ede5-9716-c646-8c9a-dbe9b6885a89@pm.me> <8a298436-0538-efd1-6c81-b1788f00df6f@pm.me> Message-ID: Hi, Rob. > Why are you -1 with PromisesLocal? - Missing class comments, thus no clarification of vocabulary "ERef", "Vat", "Reactor", "Resolver", etc. - Too many extensions in Object and ProtoObject - Some unconventional wording/style such as #newWithNick:, #onOneArgClosure:...,  This is just very high-level feedback and not specific to your implementation strategy. I did not have more time yet to take a closer look, sorry. Best, Marcel Am 03.08.2020 12:55:18 schrieb Robert Withers : Hi Marcel, Why are you -1 with PromisesLocal? It is easy to add the protocol published by the current Promise class, minus the wait protocols. I can certainly rename the proxies, as well. So what specifically are you -1 abut wrt PromisesLocal? PromisesRemote is in addition to PromisesLocal, it extends several remote proxies. K, r On 8/3/20 4:21 AM, Marcel Taeumel wrote: Hi all! I like the idea of fixing Squeak's implementation of promises. However, I am -1 for adding PromiseLocal/PromiseRemote but would rather like to sse am implementation of Promise that works for both cases. Also, "PromiseERefs" and "BrokenERefs" sounds too cryptic. We can find better names here. :-) Best, Marcel Am 02.08.2020 15:48:49 schrieb Robert Withers via Squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]: Hello, there, In reading the chapter on Promises, in the section on the E programming language, of which PromisesLocal is modeled, the following needs clarification: Subsequent messages can also be eventually sent to a promise before it is resolved. In this case, these messages are queued up and forwarded once the promise is resolved. The messages are not queued up at the local promise, pending forwarding to the eventual result; they are forwarded to a promise, local to the computation. This is mainly important once you have introduced remote promises (PromisesRemote). Messages are sent to the computation and they queue up local, for execution upon the eventual value, #whenMoreResolved:. K, r NB: here is a chained message sending eventually, with Promises. ((10 eventual factorial / 100) * 25)     whenResolved: [:i | i value]. On 8/2/20 8:55 AM, Robert Withers wrote: Hi all'y'all! Here is a textbook on Promises, for your understanding. [Inspired by functional programming, one of the major distinctions between different interpretations of this construct have to do with pipelineing or composition. Some of the more popular interpretations of futures/promises make it possible to chain operations, or define a pipeline of operations to be invoked upon completion of the computation represented by the future/promise. This is in contrast to callback-heavy or more imperative direct blocking approaches.] http://dist-prog-book.com/chapter/2/futures.html [http://dist-prog-book.com/chapter/2/futures.html] K, r On 8/1/20 12:09 PM, Robert Withers wrote: Good afternoon! I wish to offer a proposal for discussion to include PromisesLocal into trunk and to replace the implementation of Promise/BrokenPromise with PromiseERefs and BrokenERefs. The underlying concurrency model has explicit use of an event loop in PromisesLocal. The code size is minimal but adds the Promises/A+ specification to Squeak, that can be extended into a remote reference solution and an Agent communications architecture. Exceptions are processed. I want to define a VatSemaphore that allows the user to #wait/#signal, and they get 'immediate' control flow which most folks find as a valid way to describe steps taken.Under the covers the VatSemaphore is connected to the Vat, as an element in a forthcoming continuationPool. So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the continuation is captured and placed in the pool and the vat's event loop continues with the next event. When #signal is sent to this VatSemaphore, the continuation is scheduled: in the queue and removed from the pool. The event loop will process the continuation. On 7/28/20 3:41 PM, Jakob Reschke wrote: My other suspicion is that we would nevertheless need an extended debugger to deal well with such eventual control flow. A debugger with a "step to resolution" or so that steps to the point where the messages are eventually answered, or the receiver even activated. I think that this is a great idea! Research in this direction would be AWESOME! On 8/1/20 11:39 AM, Robert Withers wrote: On 7/28/20 3:41 PM, Jakob Reschke wrote: Current Kernel Promises are also not good at that without sprinkling breakpoints... This and the dreadful error handling ("well so I forgot the block argument for the callback again and got an error from value:, now how do I find out in the debugger which method even contains my wrong block?!?" What if the debugger could allow you to browse reactor creation methods? Where is the closure created? I can imagine an implementation of EIO (http://wiki.erights.org/wiki/EIO_Redesign [http://wiki.erights.org/wiki/EIO_Redesign]), Eventual I/O, that has a #whenAvailable: semantic. Then the UI event loop is just an EInputStream and we could flip the entire system over to using a promise architecture. Kindly, rabbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.withers at pm.me Mon Aug 3 15:41:49 2020 From: robert.withers at pm.me (Robert Withers) Date: Mon, 03 Aug 2020 15:41:49 +0000 Subject: [squeak-dev] [Proposed] include PromisesLocal in trunk In-Reply-To: References: <7c8ad646-d5c3-9da8-93fc-0ef6be932163@pm.me> <265e61a3-00a4-ee10-eb88-3c3741418cb7@pm.me> <99b4ede5-9716-c646-8c9a-dbe9b6885a89@pm.me> <8a298436-0538-efd1-6c81-b1788f00df6f@pm.me> Message-ID: <87dd1d29-1f73-2a33-195c-a13222626899@pm.me> Thank you, Marcel! Great feedback, I will look to it. K, r On 8/3/20 10:48 AM, Marcel Taeumel wrote: > Hi, Rob. > >> Why are you -1 with PromisesLocal? > > - Missing class comments, thus no clarification of vocabulary "ERef", "Vat", "Reactor", "Resolver", etc. > - Too many extensions in Object and ProtoObject > - Some unconventional wording/style such as #newWithNick:, #onOneArgClosure:..., > > This is just very high-level feedback and not specific to your implementation strategy. I did not have more time yet to take a closer look, sorry. > > Best, > Marcel > >> Am 03.08.2020 12:55:18 schrieb Robert Withers [](mailto:robert.withers at pm.me): >> >> Hi Marcel, >> >> Why are you -1 with PromisesLocal? It is easy to add the protocol published by the current Promise class, minus the wait protocols. I can certainly rename the proxies, as well. So what specifically are you -1 abut wrt PromisesLocal? >> >> PromisesRemote is in addition to PromisesLocal, it extends several remote proxies. >> >> K, r >> >> On 8/3/20 4:21 AM, Marcel Taeumel wrote: >> >>> Hi all! >>> >>> I like the idea of fixing Squeak's implementation of promises. However, I am -1 for adding PromiseLocal/PromiseRemote but would rather like to sse am implementation of Promise that works for both cases. Also, "PromiseERefs" and "BrokenERefs" sounds too cryptic. We can find better names here. :-) >>> >>> Best, >>> Marcel >>> >>>> Am 02.08.2020 15:48:49 schrieb Robert Withers via Squeak-dev [](mailto:squeak-dev at lists.squeakfoundation.org): >>>> >>>> Hello, there, >>>> >>>> In reading the chapter on Promises, in the section on the E programming language, of which PromisesLocal is modeled, the following needs clarification: >>>> >>>>> Subsequent messages can also be eventually sent to a promise before it is resolved. In this case, these messages are queued up and forwarded once the promise is resolved. >>>> >>>> The messages are not queued up at the local promise, pending forwarding to the eventual result; they are forwarded to a promise, local to the computation. This is mainly important once you have introduced remote promises (PromisesRemote). Messages are sent to the computation and they queue up local, for execution upon the eventual value, #whenMoreResolved:. >>>> >>>> K, r >>>> >>>> NB: here is a chained message sending eventually, with Promises. >>>> >>>>> ((10 eventual factorial / 100) * 25) >>>>> whenResolved: [:i | i value]. >>>> >>>> On 8/2/20 8:55 AM, Robert Withers wrote: >>>> >>>>> Hi all'y'all! >>>>> >>>>> Here is a textbook on Promises, for your understanding. >>>>> >>>>>> [Inspired by functional programming, one of the major distinctions between different interpretations of this construct have to do with pipelineing or composition. Some of the more popular interpretations of futures/promises make it possible to chain operations, or define a pipeline of operations to be invoked upon completion of the computation represented by the future/promise. This is in contrast to callback-heavy or more imperative direct blocking approaches.] >>>>> >>>>> http://dist-prog-book.com/chapter/2/futures.html >>>>> K, r >>>>> >>>>> On 8/1/20 12:09 PM, Robert Withers wrote: >>>>> >>>>>> Good afternoon! >>>>>> >>>>>> I wish to offer a proposal for discussion to include PromisesLocal into >>>>>> trunk and to replace the implementation of Promise/BrokenPromise with >>>>>> PromiseERefs and BrokenERefs. The underlying concurrency model has >>>>>> explicit use of an event loop in PromisesLocal. The code size is minimal >>>>>> but adds the Promises/A+ specification to Squeak, that can be extended >>>>>> into a remote reference solution and an Agent communications >>>>>> architecture. Exceptions are processed. >>>>>> >>>>>> I want to define a VatSemaphore that allows the user to #wait/#signal, >>>>>> and they get 'immediate' control flow which most folks find as a valid >>>>>> way to describe steps taken.Under the covers the VatSemaphore is >>>>>> connected to the Vat, as an element in a forthcoming continuationPool. >>>>>> So a Vat is {stack, queue, pool, eventLoop}. When #wait is sent, the >>>>>> continuation is captured and placed in the pool and the vat's event loop >>>>>> continues with the next event. When #signal is sent to this >>>>>> VatSemaphore, the continuation is scheduled: in the queue and removed >>>>>> from the pool. The event loop will process the continuation. >>>>>> >>>>>>>> On 7/28/20 3:41 PM, Jakob Reschke wrote: >>>>>>>> My other suspicion is that we would nevertheless need an extended >>>>>>>> debugger to deal well with such eventual control flow. A debugger >>>>>>>> with a "step to resolution" or so that steps to the point where the >>>>>>>> messages are eventually answered, or the receiver even activated. >>>>>>> >>>>>>> I think that this is a great idea! >>>>>> >>>>>> Research in this direction would be AWESOME! >>>>>> >>>>>> On 8/1/20 11:39 AM, Robert Withers wrote: >>>>>> >>>>>>>> On 7/28/20 3:41 PM, Jakob Reschke wrote: >>>>>>>> Current Kernel Promises are also not good at that without sprinkling >>>>>>>> breakpoints... This and the dreadful error handling ("well so I >>>>>>>> forgot the block argument for the callback again and got an error >>>>>>>> from value:, now how do I find out in the debugger which method even >>>>>>>> contains my wrong block?!?" >>>>>>> >>>>>>> What if the debugger could allow you to browse reactor creation >>>>>>> methods? Where is the closure created? >>>>>> >>>>>> I can imagine an implementation of EIO >>>>>> ( >>>>>> http://wiki.erights.org/wiki/EIO_Redesign >>>>>> ), Eventual I/O, that has a >>>>>> #whenAvailable: semantic. Then the UI event loop is just an EInputStream >>>>>> and we could flip the entire system over to using a promise architecture. >>>>>> >>>>>> Kindly, >>>>>> rabbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From digit at sonic.net Mon Aug 3 17:27:16 2020 From: digit at sonic.net (Tim Johnson) Date: Mon, 3 Aug 2020 10:27:16 -0700 Subject: [squeak-dev] Survey: Cmd-s to close a dialog? (was: 5.3, focus follows mouse, image "save as...") In-Reply-To: References: <23539013-D464-4CC6-89B2-26B451C2338E@sonic.net> Message-ID: The Orange Book specifically lists 'accept' in the Menu Command Index, page 510 in my edition. It separates out its instances in the book by 'to compile' and 'to store'. The second paragraph on page 37 describes what happens if a user tries to dismiss a dialog with changes, without the user clicking 'accept' or 'cancel'. I realize this is all MVC and ancient history by now (?), but I first started learning & understanding Squeak by using the Orange Book & Blue Book in Squeak's early MVC and Morphic environments. Squeak hadn't diverged much, in MVC or in Morphic, by 3.8/3.9/3.10 or so. Nowadays, I'm not sure how helpful it is that I am mentioning a 36- year-old book. :) The definition of 'undo' on page 58 is also interesting: it seems like it was never meant to replace 'accept'/'cancel', but was meant to exist beside these and remain a tool of its own. Thus the MVC environment could be said to have given the user two levels of 'undo'. On Aug 1, 2020, at 4:22 PM, Chris Muller wrote: > It used to be that Cmd+s would remember the contents of text fields > in windows, so that if I then made further modifications to it which > I *then* change my mind about, I could press Cmd+l (lowercase L), to > restore it to the last-accepted state. I really miss that in > Workspaces and inspectors. > > But it should never close a multifield dialog, IMO. Maybe it > shouldn't even for FillInTheBlank either, for consistency. > > - Chris > > On Sat, Aug 1, 2020 at 7:28 AM Jakob Reschke > wrote: > Hi Chris, > > Chris Muller schrieb am Fr., 31. Juli 2020, > 22:47: > > *but* > > It would be a problem in dialogues with several input fields though; > see for example the SqueakMap edit tool. > > That's different. Not modal. Just like the code browser, where you > don't want Cmd+s to close the code browser. But for modal dialogs, > yes, ... > > What do you think about windows that are input requesting dialogs, > but not modal, as in: prevents other interactions while it is open? > The commit dialog of the Git Browser falls into this category. But > even though the Monticello save dialog will claim to be modal if its > process is interrupted, it isn't really since you can do other > things while it is open. So you could also answer with the > Monticello save window in mind. Or the Monticello merge tool, which > does not have text input for a change. > > Kind regards, > Jakob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Mon Aug 3 21:06:57 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 3 Aug 2020 17:06:57 -0400 Subject: [squeak-dev] Squeak News from 2001 In-Reply-To: <78401217-5fa9-a84f-94fe-dbda89cc610a@leastfixedpoint.com> References: <78401217-5fa9-a84f-94fe-dbda89cc610a@leastfixedpoint.com> Message-ID: <20200803210657.GA28672@shell.msen.com> Wow, there's Tim Rowledge's article about "VMMaker - a tool to make VM making simpler", right there in the first edition of SqueakNews. It looks like this was from even before he made the UI tool (which BTW still works fine all these years later). SqueakNews was and still is a wonderful thing, thanks for putting it on line with SqueakJS. Dave On Mon, Aug 03, 2020 at 09:17:54AM +0200, Tony Garnock-Jones wrote: > This is wonderful, Vanessa! Thank you very much! > > (I'm particularly delighted to see Ted Kaehler's "A Most Unusual Method > Finder" article; it'll be something I can point people toward next time > they ask for a reference.) > > Regards, > Tony > > > > On 8/3/20 3:47 AM, Vanessa Freudenberg wrote: > > Hi all, > > > > Squeak News was a multimedia e-zine published by Tansel Ersavas in 2001 > > as Squeak images on CD-ROM. Each issue contains contributions from many > > people in our community. I build a web viewer using SqueakJS: > > https://smalltalkzoo.computerhistory.org/SqueakNews/index.html > > > > The source??code is on GitHub: > > https://github.com/squeak-smalltalk/squeaknews > > Contributions welcome! > > > > If you find something that doesn't work correctly, please file a bug > > report on github. > > > > Enjoy! > > Vanessa > > > > I'm copying the table of contents below: > > > > > > Volume 1 Issue 1, July 2001 > > > > > > Open Issue #1 > > > > > > Cover Page > > Did you have fun with our cover page? We certainly did. A little > > heavy with animation, a little slow on slower machines, but still > > enjoyable. So if at any point you would like to return to it please > > feel free. > > Our First Issue > > What On Earth Are We Doing???by Tansel Ersavas > > Well, now you know. Read all about it in this editorial note. > > This month in the Squeak World??by Bijan Parsia > > This month's news include summaries of the activity of the Squeak > > list and the Squeak foundation list. Squeak in the press and Squeak > > Central's new move is high on the agenda. > > Mini E-View with Dan Ingalls > > Do not miss this mini E-view with Dan Ingalls about the latest move > > of Squeak Central and future of Squeak! > > A Most Unusual Method Finder??by Ted Kaehler > > In this essay Ted takes us through the Method finder and the idea > > behind it. Ted explains how he started writing the method finder, > > how it works, how the symbol table is searched, how "methods by > > example" works and how method finder handles an exhaustive search > > without causing any damage to the system. > > Interview with John Maloney > > Part 1: Before Apple > > In the first part of this in-depth interview, we talked with John > > about the early days: how he started working with Smalltalk, his > > early Xerox days, the origins of Celeste, his experience with other > > systems, constraint based programming, Self and the birth of Morphic. > > VMMaker - a tool to make VM making simpler??by Tim Rowledge > > In this article, Tim explains the VmMaker and the motive behind it. > > Tim's VmMaker makes the process of generating VMs much easier. Tim > > explains the usage of VmMaker and he states possible enhancements to it. > > The Foundations of SqueakNOS??by the SqueakNOS team / Luciano Notarfrancesco > > SqueakNOS is an ambitious project that aims to strip that useless > > huge nappy padded underwear of computers that is called an > > "operating system" and replace it with a layer all written in > > Squeak! Here the SqueakNOS team explain how they intend to do it, > > what they have done so far, how they have done it, and what they aim > > to do. > > Squeak Tweaks: Celeste as a Mailing List Summarizer??by Bijan Parsia > > In this corner of the e-zine, Bijan will show us how to tweak Squeak > > with interesting insights. > > In his first article Bijan takes Celeste and turns it into a mail > > list summarizer! He explains the need for the mail summarizer (after > > all he volunteered for the Squeak News monthly email summaries!) and > > step by step explains how Celeste is turned into a handy mail > > summarizer sidekick. After reading this article you will have a good > > idea about how he can categorize and sift through the enormous > > amount of email that Squeak list generates with a little help from > > his new Celeste-MLS! > > Squeak Documentation Initiative > > Squeak Documentation initiative is a Squeak News sponsored activity > > that will start with this issue. Here we will explain mechanisms and > > ask for volunteers for this initiative. The goal is to create a > > giant living reference manual and a reference server that any Squeak > > that is on the net can hook up to and access to on-line > > documantaion. This documentation will be in a form that can be > > embedded in any image and will have built in mechanisms to update > > itself when changes are made and post these updates to a central > > server or other peers. Another useful document is a user guide which > > will also be semi-automatically generated. Documentation swiki pages > > will be used to capture most additions and modifications to the > > documentation. More details will soon be available from the Squeak > > News site. > > Fun with Squeak: Learn to Juggle with Squeak??by Tansel Ersavas > > In this article Tansel takes you to a journey that will juggle two > > things at once: learning juggling while writing a tutorial that > > teaches juggling. It is a meta-juggling tutorial that is a lot of > > fun. Most aspects of juggling from choosing the right balls to how > > not to juggle with raw eggs are clearly illustrated with animated > > examples > > Squeak Notebook??by Torsten Bergmann > > A little example of how a SqueakBook can look like a notebook > > Best of Bob's SuperSwiki: Squeak or How the Mouse Roars > > Each month we will feature a project published in Bob's super Swiki > > or other public Super Swikis. This month we feature the first part > > of Torsten Bergman's HTMR: Squeak or How the Mouse Roars' series. > > Squeak Graphics??by Ali Chamas > > Graphics created by Ali Chamas using Squeak captured the attention > > of many people and some of these graphics were featured in web sites > > such as flipcode.com . See them yourself. > > This Month's Quiz: Detecting an Alarm via Email from a Remote Location > > Tributes: Pat Caudill and Jerry Archibald > > This month we have lost 2 Smalltalkers. Pat Caudill (1945-2001) > > passed away June 14, 2001, and Jerry Archibald (1940-2001) passed > > away June 22, 2001. > > > > All Issues > > > > > > > > Volume 1 Issue 2, 15 August 2001 > > > > > > Open Issue #2 > > > > > > Focus on Beginners > > Starting with this issue we will focus on beginners and every issue > > of Squeak News will feature at least one article targeted at > > beginners. This month we feature two articles that would help > > beginners. You will also find in this issue very interesting > > articles about hardware that can run Squeak, a very interesting user > > interface framework for UI development specifically tailored towards > > PDAs and Kiosk style applications. The Squeak Tweaks corner will > > feature a quickie HTML editor. For the diehards who are determined > > to rip the operating system under Squeak the current installment of > > the SqueakNOS series is "Story of the Quake Packet". You will also > > find the conclusion of the Juggling article and continuation of our > > in-depth interview with John Maloney. > > Squeak Related News > > This month's news include summaries of the activity of the Squeak > > list and the Squeak foundation list and our report on fun new > > hardware to play with Squeak > > Monthly digest of the Squeak Mailing list??by Bijan Parsia > > Every month Bijan summarizes the Squeak mailing list painstakingly > > by organizing postings under threads with commentary using home-bred > > tools that he developed. (and explained some of them in the July > > issue) If you are busy and can't follow the fast pace of the Squeak > > list this is the column to read! This section will be emailed to our > > email subscribers as well as posted on the on the web. > > Mean Squeak Machines > > In these articles we chase our DynaBook dreams and look at some of > > the latest systems from super PDAs to desktop units that can run > > Squeak happily. > > Cool Peripherals > > We also investigate some peripherals that can enhance our Squeak > > experience from tablet-screens to solid-state USB disk units that > > are attached to key-rings. > > How to Begin Squeak??by Tansel Ersavas > > This article is the first of a series about Squeak that aims to take > > a person from the beginner stage to the level of a highly > > sophisticated programmer during the course of this (long) series. In > > this article, Tansel outlines basic concepts of object oriented > > approach and Squeak. He emphasizes differences between Squeak and > > most other languages, explains why it is harder for people who have > > been exposed to other languages to learn Squeak and suggests > > strategies that would accelerate the learning process. > > An Approach for Teaching and Learning Squeak??by Michael Guenter > > Michael brings us the experience of a teacher and proposes an > > approach for learning and teaching Squeak. He defines different > > kinds of newbies and discusses best approach for them and elaborates > > on his "study buddies" idea which has already attracted interest. > > Control your Submorphs??by Ted Kaehler and Andreas Raab > > In this active article Ted and Andreas take us to a tour of the new > > layout mechanism of morphs recently introduced to Squeak by Andreas > > Raab. As nicely stated by Ted: "Why talk about something when you > > can see it in action", this article will come to life when playing > > with it very true to the soul of Squeak News. > > The second part of an In-depth Interview with John Maloney > > In the second part of this in-depth interview, John talks about the > > Apple days, the birth of Squeak, how Squeak became on open source > > project, and how his expectations were exceeded with community > > support. We also discussed with him about the past life of Morphic > > before Squeakt. > > A Minimal User Interface Toolkit for PDAs and Kiosks??by Tansel Ersavas > > In this article Tansel introduces us to a very basic set of tools > > that help us implement simple user interfaces especially suitable > > for point and click applications. These applications are more likely > > to be useful on environments where using Morphic is not feasible > > such as small PDAs and Kiosk applications that operate on hardware > > with limited resources and where the input is limited to a touch > > screen or stylus input. > > Story of a Quake Packet??by the SqueakNOS team > > Do you know what these naughty people at the SqueakNOS team do when > > their workmates go into a frenzy of playing Quake? They peep the > > network activity using nothing other than their naughtier > > collaborator Squeak! Read this captivating story of intrigue and > > deception, and find out all about those Quake packets that lurk at > > your network pipes while people are playing Quake!. > > Squeak Tweaks: A Quickie HTML Editor??by Bijan Parsia > > In this corner of the e-zine, Bijan shows us how to tweak Squeak > > with interesting insights. > > In this article Bijan has a go at a quickly put together HTML editor > > which could be the beginning of a HTML editor liberator! > > Juggle with Squeak??by Tansel Ersavas > > In this part of this series Tansel finally puts his act together > > (almost), both about juggling, and finishing this tutorial, and the > > rest of the people can finally juggle. He still has to write about > > the beautification process though. > > Squeak Documentation initiative > > Squeak Documentation initiative is a Squeak News sponsored activity > > that will continue with this issue. This month's initiative will be > > discussed on our documentation SWiki later when the documentation > > SWiki is up and running. > > Squeak quiz with surprize rewards > > Every month, we have a question that addresses a specific problem > > and collect all answers. We will then publish selected answers and > > declare one as the "editor's choice". The person who sent the > > selected solution will receive a mystery reward from us. > > > > All Issues > > > > > > > > Volume 1 Issue 3, 15 September 2001 > > > > > > Open Issue #3 > > > > > > Squeak for a Better World! > > We changed our theme to Squeak for a Better World after the tragic > > events of September 11. Read all about the shock, frustrations and > > ideas about Squeak for a better world. > > Focus: Multimedia > > There is a lot in Squeak News this month. Close to the end of this > > month is the 5th anniversary of the day Squeak was placed on the > > Internet for the rest of the world to enjoy and we e-talked with Dan > > Ingalls about this most important event. The focus of this issue is > > Squeak and Multimedia and we have a significant amount of content > > about the subject. We feature two interactive demos: Squeak Cinema: > > A demo of the Squeak MPEG player, and SqueakAmp: The Squeak MP3 > > player. In addition we feature an article about the MPEG player of > > Squeak by John McIntosh, the full set of the active essays on > > studying computer music by Mark Guzdial and an article about > > PhotoSqueak by Juan Manuel Vuletich. Karl Ramberg's contribution is > > a short active essay about Art and Computers. Our beginners series > > focus is objects, messages and beyond. An example of system level > > programming in Squeak is given in the article "The SqueakNOS > > keyboard". We also solicited an article about one of the recent > > developments about Squeak GemStone connectivity and we are happy to > > feature this article about GemSqueak. > > Squeak Related News > > This month's news include an E-view with Dan Ingalls, summaries of > > the activity of the Squeak list and John McIntosh' Essen STUG reports. > > Squeak's 5th Birthday! An e-view with Dan Ingalls > > After looking at all the evidence we decided that the 25th September > > 1996 was the day Squeak was unleashed to us mortals (incidentally > > after about 9 months of incubation)! We declared this day to be > > Squeak's "birth" day. We asked Dan about that day, a little earlier, > > and a little later, and Dan answered! > > Monthly digest of the Squeak Mailing list??by Bijan Parsia > > Every month Bijan summarizes the Squeak mailing list painstakingly > > by organizing postings under threads with commentary using home-bred > > tools that he developed. (and explained some of them in the July > > issue) If you are busy and can't follow the fast pace of the Squeak > > list this is the column to read! This section will be emailed to our > > email subscribers as well as posted on the on the web. > > The World of Squeak: Objects, Messages and Beyond??by Tansel Ersavas > > This article is the second installment of a series about Squeak that > > aims to take a person from the beginner stage to the level of a > > highly sophisticated programmer during the course of this (long) > > series. In this article, Tansel explains the basic concepts of > > Squeak such as objects, messages and relationships between objects. > > Active Essays for Studying Computer Music??by Mark Guzdial > > If Mark Guzdial isn't an institution, he should be made into one. > > Author/instigator/editor of the two current Squeak books, hacker of > > PWS & the original Swiki, hoster of Swikis, teacher of Squeak... He, > > his students, and his classes are always throwing out cool stuff for > > the rest of us. For his class on "Computer Music Implementation", he > > wrote a series of active essays, which cover everything from the > > built in Squeak sound tools to MIDI. Aside from being nicely > > written/constructed on interesting topics -- i.e., an enjoyable read > > -- they are great examples of active essays. Mark was kind enough to > > let us feature the entire series in Squeak News with a bonus > > introduction that puts these great active essays in perspective. > > MPEG: Finding a Fit??by John McIntosh > > Among all these activities that keeps us all informed about what is > > going on around the world, John found the time to write about that > > magical plug-in that enables us to play highly compressed video and > > from within the comforts of Squeak. > > Squeak Cinema > > A showcase of the MPEG player and some of Squeak's presentation > > abilities. It features a trailer of a movie to be released next year > > by 20th Century Fox (C) 20th. Century Fox. The main feature is named > > "The Killer Bean Part 2, The Party" short masterpiece by Jeff Lew, > > slighltly over 6 minutes. This is an animation fully done by the > > author himself in 3 years on one computer. After the movie was > > released on the net it was downloaded more than 1 million times and > > helped him to join to the ranks of Hollywood's magic makers and he > > has been involved in movies such as the Matrix and the Matrix 2. We > > wish to advise our audiance that the movie contains strong violance > > and people who can't watch coffee beans destroyed should refrain > > from watching the movie. Sorry? What? No we don't have any grudges > > against coffee in any shape and we haven't hired the killer bean for > > any jobs. > > SqueakAmp: Squeak's MP3 player > > A demonstration of the MP3 playback ability of Squeak that is > > written by Bob Hartwig using the MPEG plug-in. > > Art, Computers??by Karl Ramberg > > Karl tosses questions about Art and Computers and starts > > experimenting in this short and sweet active essay... > > The Conclusion of our In-depth Interview with John Maloney > > In the conclusion of this in-depth interview, we talked with John > > about Morphic, how it differed from the original Self Morphic, and > > what is in the crystal ball for Morphic. We also talked about the > > Disney days, some projects that John got involved and more... > > The Squeak Keyboard: An Introduction to Low Level Programming in > > SqueakNOS??by the SqueakNOS team > > This article explains how Squeak handles keyboard programming from > > within SqueakNOS. Don't try this code at home! It will only work > > within SqueakNOS. > > PhotoSqueak: An Image Processing Framework??by Juan Manuel Vuletich > > What started as a school project may well turn out to be a powerful > > general purpose digital image processing system for Squeak. Learn > > all about it. > > GemSqueak: A Full Functional GemStone Client??by Valeria Murgia > > GemSqueak is a full featured and full functional GemStone client. > > Valeria Murgia with collaboration by Leandro Caniglia explains this > > exciting project. Keep an eye for their SqueakAttic OODB project as > > well. > > Book Summary: Squeak's First Book and Multimedia > > This is the first book summary published in Squeak News and > > naturally it is about the first book on Squeak ever published. > > Globe??by Torsten Bergmann > > A cool demo of 3D on a background created by the author. > > Juggle with Squeak??by Tansel Ersavas > > In this part of the series Tansel beautifies the Juggling Scene and > > explains how to create a simple user interface for the Juggling demo. > > Squeak quiz with surprize rewards > > This month we will not have a Squeak quiz, instead we are preparing > > a Squeak Challenge > > > > All Issues > > > > > > > > Volume 1 Issue 4, 15 October 2001 > > > > > > Open Issue #4 > > > > > > > > /Powerful Ideas in the Classroom/ > > > > Editor's Note > > Monthly News: > > This month's news include summaries of the activity of the Squeak > > list and John McIntosh's OOPSLA trip reports. > > Monthly digest of the Squeak Mailing list??by Bijan Parsia > > Every month Bijan summarizes the Squeak mailing list painstakingly > > by organizing postings under threads with commentary using home-bred > > tools that he developed. (and explained some of them in the July > > issue) If you are busy and can't follow the fast pace of the Squeak > > list this is the column to read! This section will be emailed to our > > email subscribers as well as posted on the on the web. > > OOPSLA Trip Reports??by John McIntosh > > John is an avid follower and documenter of almost every event. We > > asked if he would allow his excellent OOPSLA trip reports that are > > published on his site to be included in Squeak News and he kindly > > allowed us to include them with the Squeak News e-zine. Once we > > merged these reports with pictures of Michael Rueger it turned out > > to be a lively digest, just like if you were there! > > Features > > Stronger Goals for Education??by Alan Kay > > In this article Alan defines stronger goals for education and > > explains the role of Squeak in this picture. A must read for all > > parties who have an interest in education. > > Treasures Unearthed: Alan Kay's Active Essays and Articles > > We used this opportunity to feature many of Alan's past articles and > > active essays. As always Alan was very generous in allowing us to > > reprint these immense treasures in our colorful format and we have > > tried to illustrate them a little as well. > > Authoring??by Alan Kay > > This is the introduction published on SqueakLand.org. It is a short > > but a very powerful article summarizes the purpose and the origin of > > Squeak > > EToys and SimStories in Squeak??by Alan Kay > > This is a well known active essay by Alan Kay also featured on > > SqueakLand.org. In this active essay Alan shows us how simple > > scripting can be used to explain ideas that can't easily be > > explained. It explains the power of the Etoy system, the concept of > > active essays, why Etoys are important to science and math, and how > > Etoys are envisioned to be used in such active essays to even > > encyclopedias. A must read and should be in the pockets of every > > trainer! > > Computers, Networks and Education??by Alan Kay > > In this classic originally printed in Scientific American in > > September 1991 issue Alan > > Science Already IS Art!??by Alan Kay > > A short and sweet article originally written for The San Jose Museum > > of Technology brochure. > > We will also publish more of Alan Kay's articles next month > > Squeak in the Open Charter School??by B.J. Allen-Conn > > B.J. has been involved in teaching children about interactive > > computing environments since 1986. Benefit from her experience in > > teaching Squeak to children. There are several examples of students > > of the Open Charter School. Be sure to check them all. > > The Big Race!??by Open Charter School students > > Don't miss this Grand Prix of cars developed by students racing to > > capture the elusive championships. The creativity of students shine > > when cars of all colors and shapes take on each other at the track! > > Interactive Web-based Modeling and Explorations??by Naala Brewer > > In this article Naala details her interactive web-based explorations > > with students during the course of her teaching of interactivity > > through Squeak. > > Etoy examples??by various students > > Cool examples of ingenious usage of Squeak Etoy system by students > > in 4th and 5th grades in the Open Charter School. Be inspired by > > their creativity! > > School Squeaking??by Cathleen Galas > > Cathleen teaches at the Seeds University Elementary School, which is > > the laboratory school for the Graduate School of Education and > > Information Studies, UCLA. As a teacher already experienced in > > introducing kids to the Microworlds logo she details her experience > > with Squeak and Squeak's advantages over other systems. Her > > illuminating observations and student feedback make an excellent > > case for Squeak's use in the classroom. > > Youngest Users of Squeak Speak > > Feedback by some of the youngest users of Squeak > > Etoys: Squeak as an Authoring System for Kids (and Kids at Heart!!) > > We feature every tutorial we can find about the Etoy system by > > various authors. Enjoy them all! > > Squeak News Exclusive Interview with Kim Rose > > This month we had a chance to talk to Kim Rose (co-Director of the > > Viewpoints Research Institute: now home of Squeak Central, long term > > member of the Squeak Central, co-editor of the book Squeak: Open > > Personal Computing and Multimedia) in depth about how she got > > involved in computing and Squeak, media and cognitive science, her > > interest and efforts in Squeak and kids, Apple days, Disney days, > > and post Disney. This month we will publish Part 1 of this 3 part > > series. > > Plugging in Squeak??by Michael Rueger > > In this article Michael takes us from the beginning and tells us how > > the Squeak plug-in came to life, where was it first used, how is it > > used and what is and what is not in the pipeline. > > As a courtesy to our subscribers we include the plug-in installers > > for various platforms for you to save you some download time. > > From objects to classes??by Tansel Ersavas > > This article is the third installment of a series about Squeak that > > aims to take a person from the beginner stage to the level of a > > highly sophisticated programmer during the course of this (long) > > series. In this article, Tansel explains the concept of a class, how > > classes and objects are related, and how classes are related to each > > other. > > A Minimal Multimedia Manager for PDAs and Kiosks??by Tansel Ersavas > > This article will be published on our SWiki later due to heavy > > commitments and health problems of the author. We apologize. > > Juggle with Squeak??by Tansel Ersavas > > In this part of the series Tansel finishes the demo and packages it > > with a gift wrap! > > Little Butterfly > > A little poem by a very sweet girl! > > Squeak's Most Wanted List > > Starting this issue we will create a "Most Wanted list" for Squeak > > and offer some rewards. Since it will be on an SWiki page you are > > free to add your "most wanted feature or function" to the list. In > > every issue of Squeak we will recite the top of the list, newcomers > > to this list and report progress if any. This month there is a grand > > challenge: Target:Advance > > > > All Issues > > > > > > > > Volume 1 Issue 5, November 2001 > > > > > > Open Issue #5 > > > > > > > > /Future Technologies that may impact Squeak/ > > > > Editorial > > The Squeak Mailing List Summary > > Actually, this month it is not a summary, but an entire dump of all > > the mails in the mailing list. > > Future Technologies that may Impact Squeak??by Tansel Ersavas > > In this issue of Squeak News we decided to have a quick trip to the > > near future and come back with some gossip about what might impact > > Squeak and in what ways. > > Mean Squeak Machines: Futuristic Toys > > Continuing our future theme is the seciton on mean Squeak machines: > > Futuristic toys. Enjoy them! > > A Simple Task Management Tool??by Tansel Ersavas > > This article introducs a simple task management tool which could be > > used as a simple project management tool as well as a task > > scheduling tool. > > Alan Kay Treasure Chest > > In this issue we continue to publish past Alan Kay articles. This > > month we feature two more of his famous articles. > > Global Village or Global Civilization???by Alan C. Kay > > Revealing the Elephant: The Use and Misuse of Computers in Education??by > > Alan C. Kay > > The Rolodex Tutorial??by John Hinsley > > Here at last John Hinsley's Rolodex Tutorial in pure Squeak! > > SUnit Explained??by Stephane Ducasse > > A clear and detailed explanation of the SUnit framework useful not > > only for using the framework but also discusses the issues related > > to the imporatnce and practicability of testing using SUnit. > > Squeak User Manual??by Maarten Maartensz > > Maarten has a real hard go at the elusive goal of documenting > > Squeak. His user manual is a very concrete definition of Squeak. We > > will publish the continuation of his efforts as well. > > Squeak Tweaks: Are we Still Editing HTML???by Bijan Parsia > > The short answer is, yes! > > Squeak for Beginners: A Mini tour of Squeak's Classes > > Enjoy some of Squeak's most used classes with some insider information > > Squeak News Exclusive Interview with Kim Rose: Part 2 > > A Mini Utility: Auto Save Morph > > Season's Greetings! > > > > > > > From tim at rowledge.org Mon Aug 3 23:41:57 2020 From: tim at rowledge.org (tim Rowledge) Date: Mon, 3 Aug 2020 16:41:57 -0700 Subject: [squeak-dev] Squeak News from 2001 In-Reply-To: <20200803210657.GA28672@shell.msen.com> References: <78401217-5fa9-a84f-94fe-dbda89cc610a@leastfixedpoint.com> <20200803210657.GA28672@shell.msen.com> Message-ID: <658DB4E8-C3B1-4B79-806B-A6EFECE5E229@rowledge.org> > On 2020-08-03, at 2:06 PM, David T. Lewis wrote: > > Wow, there's Tim Rowledge's article about "VMMaker - a tool to make VM > making simpler", right there in the first edition of SqueakNews. It looks > like this was from even before he made the UI tool (which BTW still works > fine all these years later). I *think* I was intending to do an article on the UI side but... y'know... life.... tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Oxymorons: Airline Food From jrmaffeo at gmail.com Tue Aug 4 02:12:40 2020 From: jrmaffeo at gmail.com (John-Reed Maffeo) Date: Mon, 3 Aug 2020 19:12:40 -0700 Subject: [squeak-dev] Squeak News from 2001 In-Reply-To: References: Message-ID: On Sun, Aug 2, 2020 at 6:48 PM Vanessa Freudenberg wrote: > Hi all, > > Squeak News was a multimedia e-zine published by Tansel Ersavas in 2001 as > Squeak images on CD-ROM. Each issue contains contributions from many people > in our community. I build a web viewer using SqueakJS: > https://smalltalkzoo.computerhistory.org/SqueakNews/index.html > > The source code is on GitHub: > https://github.com/squeak-smalltalk/squeaknews > Contributions welcome! > > If you find something that doesn't work correctly, please file a bug > report on github. > > Enjoy! > Vanessa > > I'm copying the table of contents below: > > > > I thoroughly enjoyed reading these issues of 'Squeak News'. It reminded me of the reason that I got hooked on Squeak. The people, the energy, and the vision were all very compelling. So much has changed since then, but there is still a wonderful reservoir of people, energy and vision which keeps driving Squeak forward. (Note: I am bottom posting as an homage to the early internet pioneers who understood how email and email threads should work ;-) - jrm -- John-Reed Maffeo -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Tue Aug 4 06:04:37 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 4 Aug 2020 06:04:37 0000 Subject: [squeak-dev] The Inbox: System-tcj.1168.mcz Message-ID: A new version of System was added to project The Inbox: http://source.squeak.org/inbox/System-tcj.1168.mcz ==================== Summary ==================== Name: System-tcj.1168 Author: tcj Time: 3 August 2020, 11:04:33.580572 pm UUID: 18b27ffd-6134-4a71-be76-a012d1b21b2e Ancestors: System-mt.1167 Remove stale preferences from Flash support which no longer lives in the image. Needs this accompanying change to the postscript of System package: #( compressFlashImages extractFlashInHighQuality extractFlashInHighestQuality ) do: [:pref | Preferences removePreference: pref ] =============== Diff against System-mt.1167 =============== Item was changed: ----- Method: Preferences class>>defaultValueTableForCurrentRelease (in category 'defaults') ----- defaultValueTableForCurrentRelease "Answer a table defining default values for all the preferences in the release. Returns a list of (pref-symbol, boolean-symbol) pairs" ^ #( (abbreviatedBrowserButtons false) (alternativeBrowseIt false) (annotationPanes false) (areaFillsAreTolerant false) (areaFillsAreVeryTolerant false) (automaticFlapLayout true) (automaticKeyGeneration false) (automaticPlatformSettings true) (automaticViewerPlacement true) (balloonHelpEnabled true) (balloonHelpInMessageLists false) (batchPenTrails false) (capitalizedReferences true) (caseSensitiveFinds false) (cautionBeforeClosing false) (changeSetVersionNumbers true) (checkForSlips true) (checkForUnsavedProjects true) (classicNavigatorEnabled false) (cmdDotEnabled true) (collapseWindowsInPlace false) (compactViewerFlaps false) - (compressFlashImages false) (confirmFirstUseOfStyle true) (conversionMethodsAtFileOut false) (debugHaloHandle true) (debugPrintSpaceLog false) (debugShowDamage false) (decorateBrowserButtons true) (diffsInChangeList true) (diffsWithPrettyPrint false) (dismissAllOnOptionClose false) (dragNDropWithAnimation false) (eToyFriendly false) (eToyLoginEnabled false) (enableLocalSave true) - (extractFlashInHighQuality true) - (extractFlashInHighestQuality false) (fastDragWindowForMorphic true) (fenceEnabled true) (fullScreenLeavesDeskMargins true) (haloTransitions false) (higherPerformance false) (honorDesktopCmdKeys true) (includeSoundControlInNavigator false) (infiniteUndo false) (logDebuggerStackToFile true) (magicHalos false) (menuButtonInToolPane false) (menuColorFromWorld false) (menuKeyboardControl false) (modalColorPickers true) (mouseOverForKeyboardFocus false) (mouseOverHalos false) (mvcProjectsAllowed true) (navigatorOnLeftEdge true) (noviceMode false) (okToReinitializeFlaps true) (optionalButtons true) (passwordsOnPublish false) (personalizedWorldMenu true) (postscriptStoredAsEPS false) (projectViewsInWindows true) (projectZoom true) (projectsSentToDisk false) (propertySheetFromHalo false) (readDocumentAtStartup true) (restartAlsoProceeds false) (reverseWindowStagger true) (roundedMenuCorners true) (scrollBarsNarrow false) (scrollBarsOnRight true) (securityChecksEnabled false) (selectiveHalos false) (showBoundsInHalo false) (showDirectionForSketches false) (showDirectionHandles false) (showFlapsWhenPublishing false) (showProjectNavigator false) (showSecurityStatus true) (showSharedFlaps true) (signProjectFiles true) (simpleMenus false) (smartUpdating true) (startInUntrustedDirectory false) (systemWindowEmbedOK false) (tileTranslucentDrag true) (timeStampsInMenuTitles true) (turnOffPowerManager false) (twentyFourHourFileStamps true) (typeCheckingInTileScripting true) (uniTilesClassic true) (uniqueNamesInHalos false) (universalTiles false) (unlimitedPaintArea false) (useButtonPropertiesToFire false) (useUndo true) (viewersInFlaps true) (warnAboutInsecureContent true) (warnIfNoChangesFile true) (warnIfNoSourcesFile true)) " Preferences defaultValueTableForCurrentRelease do: [:pair | (Preferences preferenceAt: pair first ifAbsent: [nil]) ifNotNilDo: [:pref | pref defaultValue: (pair last == true)]]. Preferences chooseInitialSettings. "! From commits at source.squeak.org Tue Aug 4 08:52:32 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Tue, 4 Aug 2020 08:52:32 0000 Subject: [squeak-dev] The Trunk: ToolsTests-mt.98.mcz Message-ID: Marcel Taeumel uploaded a new version of ToolsTests to project The Trunk: http://source.squeak.org/trunk/ToolsTests-mt.98.mcz ==================== Summary ==================== Name: ToolsTests-mt.98 Author: mt Time: 4 August 2020, 10:52:30.205047 am UUID: c6795330-9d71-bd41-811f-76dec78f8ef6 Ancestors: ToolsTests-mt.97 Based on KernelTests-tcj.350 (inbox -> treated), add a test to check whether all menu actions are actually implemented in either model or widget. Currently works for model's code-pane menus only. Test design requires agreement on communication between model and builder such as through #buildCodePaneWith:. Not yet working for MVCToolBuilder. We do need to harmonize the interfaces of MenuMorph (Morphic) and PopUpMenu (MVC), e.g., by adding #items. Not yet passing for MorphicToolBuilder bc. missing implementation of #makeProjectLink in either CodeHolder or PluggableTextMorph. :-) =============== Diff against ToolsTests-mt.97 =============== Item was changed: SystemOrganization addCategory: #'ToolsTests-Browser'! SystemOrganization addCategory: #'ToolsTests-Debugger'! SystemOrganization addCategory: #'ToolsTests-FileList'! SystemOrganization addCategory: #'ToolsTests-Inspector'! + SystemOrganization addCategory: #'ToolsTests-Menus'! Item was added: + TestCase subclass: #ToolMenusTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'ToolsTests-Menus'! Item was added: + ----- Method: ToolMenusTest>>testCodePaneMenu (in category 'tests') ----- + testCodePaneMenu + "Checks whether all menu actions are implemented in either the model or the widget." + + | builder builderSelector menuSelector result | + builder := ToolBuilder default. + builderSelector := #buildCodePaneWith:. + menuSelector := #menu. + result := Dictionary new. + + Model withAllSubclasses + select: [:modelClass | modelClass includesSelector: builderSelector] + thenDo: [:modelClass | + | model spec widget menu selectors | + result at: modelClass put: OrderedCollection new. + model := modelClass new. + spec := model perform: builderSelector with: builder. + (spec respondsTo: menuSelector) ifFalse: [ + "Little hack to allow code panes being wrapped in panels." + spec := spec children detect: [:child | + (child respondsTo: menuSelector) and: [(child perform: menuSelector) notNil]]]. + [widget := builder build: spec] on: Error do: [:ex | ex resume: nil]. + #(false true) do: [:shifted | + menu := builder build: (builder pluggableMenuSpec new items; yourself). + menu := model perform: spec menu withEnoughArguments: {menu. shifted}. + selectors := menu items collect: [:item | item selector]. + "MVC: selectors := menu selections select: [:sel | sel isSymbol]" + (result at: modelClass) + addAll: (selectors reject: [:selector | + (model respondsTo: selector) or: [widget respondsTo: selector]])]]. + + self assert: (result values allSatisfy: [:notImplementedSelectors | notImplementedSelectors isEmpty]).! From marcel.taeumel at hpi.de Tue Aug 4 08:54:45 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 4 Aug 2020 10:54:45 +0200 Subject: [squeak-dev] The Trunk: ToolsTests-mt.98.mcz In-Reply-To: References: Message-ID: ... "model or widget" because of the use of Object >> #perform:orSendTo:. Best, Marcel Am 04.08.2020 10:52:39 schrieb commits at source.squeak.org : Marcel Taeumel uploaded a new version of ToolsTests to project The Trunk: http://source.squeak.org/trunk/ToolsTests-mt.98.mcz ==================== Summary ==================== Name: ToolsTests-mt.98 Author: mt Time: 4 August 2020, 10:52:30.205047 am UUID: c6795330-9d71-bd41-811f-76dec78f8ef6 Ancestors: ToolsTests-mt.97 Based on KernelTests-tcj.350 (inbox -> treated), add a test to check whether all menu actions are actually implemented in either model or widget. Currently works for model's code-pane menus only. Test design requires agreement on communication between model and builder such as through #buildCodePaneWith:. Not yet working for MVCToolBuilder. We do need to harmonize the interfaces of MenuMorph (Morphic) and PopUpMenu (MVC), e.g., by adding #items. Not yet passing for MorphicToolBuilder bc. missing implementation of #makeProjectLink in either CodeHolder or PluggableTextMorph. :-) =============== Diff against ToolsTests-mt.97 =============== Item was changed: SystemOrganization addCategory: #'ToolsTests-Browser'! SystemOrganization addCategory: #'ToolsTests-Debugger'! SystemOrganization addCategory: #'ToolsTests-FileList'! SystemOrganization addCategory: #'ToolsTests-Inspector'! + SystemOrganization addCategory: #'ToolsTests-Menus'! Item was added: + TestCase subclass: #ToolMenusTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'ToolsTests-Menus'! Item was added: + ----- Method: ToolMenusTest>>testCodePaneMenu (in category 'tests') ----- + testCodePaneMenu + "Checks whether all menu actions are implemented in either the model or the widget." + + | builder builderSelector menuSelector result | + builder := ToolBuilder default. + builderSelector := #buildCodePaneWith:. + menuSelector := #menu. + result := Dictionary new. + + Model withAllSubclasses + select: [:modelClass | modelClass includesSelector: builderSelector] + thenDo: [:modelClass | + | model spec widget menu selectors | + result at: modelClass put: OrderedCollection new. + model := modelClass new. + spec := model perform: builderSelector with: builder. + (spec respondsTo: menuSelector) ifFalse: [ + "Little hack to allow code panes being wrapped in panels." + spec := spec children detect: [:child | + (child respondsTo: menuSelector) and: [(child perform: menuSelector) notNil]]]. + [widget := builder build: spec] on: Error do: [:ex | ex resume: nil]. + #(false true) do: [:shifted | + menu := builder build: (builder pluggableMenuSpec new items; yourself). + menu := model perform: spec menu withEnoughArguments: {menu. shifted}. + selectors := menu items collect: [:item | item selector]. + "MVC: selectors := menu selections select: [:sel | sel isSymbol]" + (result at: modelClass) + addAll: (selectors reject: [:selector | + (model respondsTo: selector) or: [widget respondsTo: selector]])]]. + + self assert: (result values allSatisfy: [:notImplementedSelectors | notImplementedSelectors isEmpty]).! -------------- next part -------------- An HTML attachment was scrubbed... URL: From forums.jakob at resfarm.de Tue Aug 4 11:18:55 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Tue, 4 Aug 2020 13:18:55 +0200 Subject: [squeak-dev] The Trunk: ToolsTests-mt.98.mcz In-Reply-To: References: Message-ID: You could provide template methods for the ToolBuilder instance or the different aspects of inspecting the menu that are UI framework-specific. Then you could have a subclass of this test case class per framework and run them all at once. Marcel Taeumel schrieb am Di., 4. Aug. 2020, 10:55: > ... "model or widget" because of the use of Object >> #perform:orSendTo:. > > Best, > Marcel > > Am 04.08.2020 10:52:39 schrieb commits at source.squeak.org < > commits at source.squeak.org>: > Marcel Taeumel uploaded a new version of ToolsTests to project The Trunk: > http://source.squeak.org/trunk/ToolsTests-mt.98.mcz > > ==================== Summary ==================== > > Name: ToolsTests-mt.98 > Author: mt > Time: 4 August 2020, 10:52:30.205047 am > UUID: c6795330-9d71-bd41-811f-76dec78f8ef6 > Ancestors: ToolsTests-mt.97 > > Based on KernelTests-tcj.350 (inbox -> treated), add a test to check > whether all menu actions are actually implemented in either model or widget. > > Currently works for model's code-pane menus only. Test design requires > agreement on communication between model and builder such as through > #buildCodePaneWith:. > > Not yet working for MVCToolBuilder. We do need to harmonize the interfaces > of MenuMorph (Morphic) and PopUpMenu (MVC), e.g., by adding #items. > > Not yet passing for MorphicToolBuilder bc. missing implementation of > #makeProjectLink in either CodeHolder or PluggableTextMorph. :-) > > =============== Diff against ToolsTests-mt.97 =============== > > Item was changed: > SystemOrganization addCategory: #'ToolsTests-Browser'! > SystemOrganization addCategory: #'ToolsTests-Debugger'! > SystemOrganization addCategory: #'ToolsTests-FileList'! > SystemOrganization addCategory: #'ToolsTests-Inspector'! > + SystemOrganization addCategory: #'ToolsTests-Menus'! > > Item was added: > + TestCase subclass: #ToolMenusTest > + instanceVariableNames: '' > + classVariableNames: '' > + poolDictionaries: '' > + category: 'ToolsTests-Menus'! > > Item was added: > + ----- Method: ToolMenusTest>>testCodePaneMenu (in category 'tests') ----- > + testCodePaneMenu > + "Checks whether all menu actions are implemented in either the model or > the widget." > + > + | builder builderSelector menuSelector result | > + builder := ToolBuilder default. > + builderSelector := #buildCodePaneWith:. > + menuSelector := #menu. > + result := Dictionary new. > + > + Model withAllSubclasses > + select: [:modelClass | modelClass includesSelector: builderSelector] > + thenDo: [:modelClass | > + | model spec widget menu selectors | > + result at: modelClass put: OrderedCollection new. > + model := modelClass new. > + spec := model perform: builderSelector with: builder. > + (spec respondsTo: menuSelector) ifFalse: [ > + "Little hack to allow code panes being wrapped in panels." > + spec := spec children detect: [:child | > + (child respondsTo: menuSelector) and: [(child perform: menuSelector) > notNil]]]. > + [widget := builder build: spec] on: Error do: [:ex | ex resume: nil]. > + #(false true) do: [:shifted | > + menu := builder build: (builder pluggableMenuSpec new items; yourself). > + menu := model perform: spec menu withEnoughArguments: {menu. shifted}. > + selectors := menu items collect: [:item | item selector]. > + "MVC: selectors := menu selections select: [:sel | sel isSymbol]" > + (result at: modelClass) > + addAll: (selectors reject: [:selector | > + (model respondsTo: selector) or: [widget respondsTo: selector]])]]. > + > + self assert: (result values allSatisfy: [:notImplementedSelectors | > notImplementedSelectors isEmpty]).! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forums.jakob at resfarm.de Tue Aug 4 11:27:02 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Tue, 4 Aug 2020 13:27:02 +0200 Subject: [squeak-dev] The Trunk: ToolsTests-mt.98.mcz In-Reply-To: References: Message-ID: This is nice to detect bad menus for a Squeak release. But it will fail if you have a non-conforming third party Model loaded. On the other hand the tests of that third party code will probably not fail. And they have no easy easy to reuse this test facility for their own classes to make their test suite fail. So: how about making the list of classes to test overridable? The base implementation could either collect all the Model subclasses as currently, or get only the classes of the Trunk packages. Of course this is a different direction for new subclasses than what I wrote in my other mail about subclasses for UI frameworks. So one of those aspects should probably be in a different object (composition) or for now just another test method. schrieb am Di., 4. Aug. 2020, 10:52: > Marcel Taeumel uploaded a new version of ToolsTests to project The Trunk: > http://source.squeak.org/trunk/ToolsTests-mt.98.mcz > > ==================== Summary ==================== > > Name: ToolsTests-mt.98 > Author: mt > Time: 4 August 2020, 10:52:30.205047 am > UUID: c6795330-9d71-bd41-811f-76dec78f8ef6 > Ancestors: ToolsTests-mt.97 > > Based on KernelTests-tcj.350 (inbox -> treated), add a test to check > whether all menu actions are actually implemented in either model or widget. > > Currently works for model's code-pane menus only. Test design requires > agreement on communication between model and builder such as through > #buildCodePaneWith:. > > Not yet working for MVCToolBuilder. We do need to harmonize the interfaces > of MenuMorph (Morphic) and PopUpMenu (MVC), e.g., by adding #items. > > Not yet passing for MorphicToolBuilder bc. missing implementation of > #makeProjectLink in either CodeHolder or PluggableTextMorph. :-) > > =============== Diff against ToolsTests-mt.97 =============== > > Item was changed: > SystemOrganization addCategory: #'ToolsTests-Browser'! > SystemOrganization addCategory: #'ToolsTests-Debugger'! > SystemOrganization addCategory: #'ToolsTests-FileList'! > SystemOrganization addCategory: #'ToolsTests-Inspector'! > + SystemOrganization addCategory: #'ToolsTests-Menus'! > > Item was added: > + TestCase subclass: #ToolMenusTest > + instanceVariableNames: '' > + classVariableNames: '' > + poolDictionaries: '' > + category: 'ToolsTests-Menus'! > > Item was added: > + ----- Method: ToolMenusTest>>testCodePaneMenu (in category 'tests') ----- > + testCodePaneMenu > + "Checks whether all menu actions are implemented in either the > model or the widget." > + > + | builder builderSelector menuSelector result | > + builder := ToolBuilder default. > + builderSelector := #buildCodePaneWith:. > + menuSelector := #menu. > + result := Dictionary new. > + > + Model withAllSubclasses > + select: [:modelClass | modelClass includesSelector: > builderSelector] > + thenDo: [:modelClass | > + | model spec widget menu selectors | > + result at: modelClass put: OrderedCollection new. > + model := modelClass new. > + spec := model perform: builderSelector with: > builder. > + (spec respondsTo: menuSelector) ifFalse: [ > + "Little hack to allow code panes being > wrapped in panels." > + spec := spec children detect: [:child | > + (child respondsTo: menuSelector) > and: [(child perform: menuSelector) notNil]]]. > + [widget := builder build: spec] on: Error do: [:ex > | ex resume: nil]. > + #(false true) do: [:shifted | > + menu := builder build: (builder > pluggableMenuSpec new items; yourself). > + menu := model perform: spec menu > withEnoughArguments: {menu. shifted}. > + selectors := menu items collect: [:item | > item selector]. > + "MVC: selectors := menu selections select: > [:sel | sel isSymbol]" > + (result at: modelClass) > + addAll: (selectors reject: > [:selector | > + (model respondsTo: > selector) or: [widget respondsTo: selector]])]]. > + > + self assert: (result values allSatisfy: [:notImplementedSelectors > | notImplementedSelectors isEmpty]).! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Tue Aug 4 12:40:16 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Tue, 4 Aug 2020 14:40:16 +0200 Subject: [squeak-dev] The Trunk: ToolsTests-mt.98.mcz In-Reply-To: References: Message-ID: Hi Jakob, it checks for "includesSelector: #buildCodePaneWith:". Should be specific enough to discard other models in the system. Of course, models can chose to implement that in a totally different way. Well, that would be bad luck. :-) Best, Marcel Am 04.08.2020 13:27:26 schrieb Jakob Reschke : This is nice to detect bad menus for a Squeak release. But it will fail if you have a non-conforming third party Model loaded. On the other hand the tests of that third party code will probably not fail. And they have no easy easy to reuse this test facility for their own classes to make their test suite fail. So: how about making the list of classes to test overridable? The base implementation could either collect all the Model subclasses as currently, or get only the classes of the Trunk packages. Of course this is a different direction for new subclasses than what I wrote in my other mail about subclasses for UI frameworks. So one of those aspects should probably be in a different object (composition) or for now just another test method. schrieb am Di., 4. Aug. 2020, 10:52: Marcel Taeumel uploaded a new version of ToolsTests to project The Trunk: http://source.squeak.org/trunk/ToolsTests-mt.98.mcz [http://source.squeak.org/trunk/ToolsTests-mt.98.mcz] ==================== Summary ==================== Name: ToolsTests-mt.98 Author: mt Time: 4 August 2020, 10:52:30.205047 am UUID: c6795330-9d71-bd41-811f-76dec78f8ef6 Ancestors: ToolsTests-mt.97 Based on KernelTests-tcj.350 (inbox -> treated), add a test to check whether all menu actions are actually implemented in either model or widget. Currently works for model's code-pane menus only. Test design requires agreement on communication between model and builder such as through #buildCodePaneWith:. Not yet working for MVCToolBuilder. We do need to harmonize the interfaces of MenuMorph (Morphic) and PopUpMenu (MVC), e.g., by adding #items. Not yet passing for MorphicToolBuilder bc. missing implementation of #makeProjectLink in either CodeHolder or PluggableTextMorph. :-) =============== Diff against ToolsTests-mt.97 =============== Item was changed:   SystemOrganization addCategory: #'ToolsTests-Browser'!   SystemOrganization addCategory: #'ToolsTests-Debugger'!   SystemOrganization addCategory: #'ToolsTests-FileList'!   SystemOrganization addCategory: #'ToolsTests-Inspector'! + SystemOrganization addCategory: #'ToolsTests-Menus'! Item was added: + TestCase subclass: #ToolMenusTest +       instanceVariableNames: '' +       classVariableNames: '' +       poolDictionaries: '' +       category: 'ToolsTests-Menus'! Item was added: + ----- Method: ToolMenusTest>>testCodePaneMenu (in category 'tests') ----- + testCodePaneMenu +       "Checks whether all menu actions are implemented in either the model or the widget." + +       | builder builderSelector menuSelector result | +       builder := ToolBuilder default. +       builderSelector := #buildCodePaneWith:. +       menuSelector := #menu. +       result := Dictionary new. + +       Model withAllSubclasses +               select: [:modelClass | modelClass includesSelector: builderSelector] +               thenDo: [:modelClass | +                       | model spec widget menu selectors | +                       result at: modelClass put: OrderedCollection new. +                       model := modelClass new. +                       spec := model perform: builderSelector with: builder. +                       (spec respondsTo: menuSelector) ifFalse: [ +                               "Little hack to allow code panes being wrapped in panels." +                               spec := spec children detect: [:child | +                                       (child respondsTo: menuSelector) and: [(child perform: menuSelector) notNil]]]. +                       [widget := builder build: spec] on: Error do: [:ex | ex resume: nil]. +                       #(false true) do: [:shifted | +                               menu := builder build: (builder pluggableMenuSpec new items; yourself). +                               menu := model perform: spec menu withEnoughArguments: {menu. shifted}.  +                               selectors := menu items collect: [:item | item selector]. +                               "MVC: selectors := menu selections select: [:sel | sel isSymbol]" +                               (result at: modelClass) +                                       addAll: (selectors reject: [:selector | +                                               (model respondsTo: selector) or: [widget respondsTo: selector]])]]. + +       self assert: (result values allSatisfy: [:notImplementedSelectors | notImplementedSelectors isEmpty]).! -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Tue Aug 4 14:41:58 2020 From: builds at travis-ci.org (Travis CI) Date: Tue, 04 Aug 2020 14:41:58 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1782 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f2973b625feb_13fce5e81d9c43038da@travis-tasks-d85bb8c6-np8s7.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1782 Status: Errored Duration: 17 mins and 36 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/714824982?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tom.Beckmann at student.hpi.uni-potsdam.de Tue Aug 4 17:57:48 2020 From: Tom.Beckmann at student.hpi.uni-potsdam.de (Beckmann, Tom) Date: Tue, 4 Aug 2020 17:57:48 +0000 Subject: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <173b42d84b7.c5e3ac7552071.3797801497954478016@zoho.com> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <7F78D9C3-85B3-4514-B85B-9A010EF6B88F@gmx.de>, <173b42d84b7.c5e3ac7552071.3797801497954478016@zoho.com> Message-ID: <95f2a478caa34c96bbfa98f0917e6828@student.hpi.uni-potsdam.de> Hey everyone, I just described our suggestion to approach a new bootstrapping process on Metacello's Github: https://github.com/Metacello/metacello/issues/524 We would appreciate it, if you could have a read through and see if you can identify potential problems or better ways to approach this, in particular also for the "Further Steps" part. Best, Tom ________________________________________ From: Squeak-dev on behalf of gettimothy via Squeak-dev Sent: Monday, August 3, 2020 1:55:48 PM To: squeak-dev at lists.squeakfoundation.org Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye Thanks all Are there steps I should be taking to help facilitate this? Thx ---- On Mon, 03 Aug 2020 06:49:47 -0400 Das.Linux at gmx.de wrote ---- > On 03.08.2020, at 10:13, Marcel Taeumel > wrote: > > Hi all! > > I think that Tom (tobe) had the idea to publish bootstrap MCZs via Metacello's GitHub releases page since it is very easy to point Monti(!)cello to such an HTML page to fetch downloadable content. In that case, we can put them on files.squeak.org, too … -t > > Best, > Marcel >> Am 02.08.2020 22:13:18 schrieb Jakob Reschke >: >> >> Probably related thread: >> http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html >> >> Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev >> : >> > >> > Hi folks, >> > >> > This probably holds for 5.3 install too. >> > >> > In the preferences wizard, the extras stuff, the Install Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" >> > >> > iirc, from the pharo discord, SmalltalkHub is going away. >> > >> > You will probably need a different repo. >> > >> > cordially, >> > >> > tty >> > >> > >> > From eric.gade at gmail.com Tue Aug 4 20:49:08 2020 From: eric.gade at gmail.com (Eric Gade) Date: Tue, 4 Aug 2020 16:49:08 -0400 Subject: [squeak-dev] TrueTypeFont and Unicode Characters In-Reply-To: References: <2791C8A5-B675-4EAF-BF94-58D1D3B2AB2F@gmx.de> Message-ID: Hello all, I wanted to revisit this issue as I'm working on it again. Back in April, Tobias mentioned the following: I'm not sure we are actually loading all glyphs. > Also note, that nothing in the font (like substitiution tables) are > actually supported :/ > sorry. > It appears that the particular ancient fonts that I'm using -- and other ancient fonts whose codepoints are now part of the Unicode standard -- make use of substitution in order to access points beyond 65535 (a full unsigned 16 bits). I know this to be true for my particular Akkadian fonts because if I dig into the code I am able to render the glyphs that TTFontReader has parsed out of the file, but only if I modify the renderGlyph:height:fgColor:bgColor:depth: message to look in the Font description's table of glyphs (rather than the codepoint sparsetable, which is 65535 entries long and has no glyphs at all in it). Is there some deep reason not to support GSUB (substitution), aside from the complexity of ligatures? Right now if a TTF file has a GSUB entry it's not even being parsed out by TTFontReader. I'm really bumping around in the dark here, but I might be able to come up with something that at least permits the use of straight 1 to 1 substitutions. Any thoughts or ideas? I'm attaching a few screenshots that can give a better idea of what I've done just to get something to render properly. I created a modified version of renderGlyph: (etc, etc). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Workspace.png Type: image/png Size: 10683 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TTFontDescription.png Type: image/png Size: 92101 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CuneiformRendered.png Type: image/png Size: 6546 bytes Desc: not available URL: From Yoshiki.Ohshima at acm.org Tue Aug 4 21:24:08 2020 From: Yoshiki.Ohshima at acm.org (Yoshiki Ohshima) Date: Tue, 4 Aug 2020 14:24:08 -0700 Subject: [squeak-dev] TrueTypeFont and Unicode Characters In-Reply-To: References: <2791C8A5-B675-4EAF-BF94-58D1D3B2AB2F@gmx.de> Message-ID: On Tue, Aug 4, 2020 at 1:49 PM Eric Gade wrote: > Hello all, > > I wanted to revisit this issue as I'm working on it again. Back in April, > Tobias mentioned the following: > > I'm not sure we are actually loading all glyphs. >> Also note, that nothing in the font (like substitiution tables) are >> actually supported :/ >> sorry. >> > > It appears that the particular ancient fonts that I'm using > -- and other ancient > fonts whose codepoints are now part of the Unicode standard -- make use of > substitution in order to access points beyond 65535 (a full unsigned 16 > bits). I know this to be true for my particular Akkadian fonts because if I > dig into the code I am able to render the glyphs that TTFontReader has > parsed out of the file, but only if I modify the > renderGlyph:height:fgColor:bgColor:depth: message to look in the Font > description's table of glyphs (rather than the codepoint sparsetable, which > is 65535 entries long and has no glyphs at all in it). > > Is there some deep reason not to support GSUB (substitution), aside from > the complexity of ligatures? Right now if a TTF file has a GSUB entry it's > not even being parsed out by TTFontReader. I'm really bumping around in the > dark here, but I might be able to come up with something that at least > permits the use of straight 1 to 1 substitutions. Any thoughts or ideas? > > I'm attaching a few screenshots that can give a better idea of what I've > done just to get something to render properly. I created a modified version > of renderGlyph: (etc, etc). > It looks very cool! The major reason is historical; using TrueType for rendering text was added with the idea that it follows the Smalltalk-80's basic text handling, e.g. the text width is the sum of individual character width, and none has non-positive advance width, etc., etc. One of the reasons is that it is not about just rendering, but if the user points within the text on screen, it'd have to figure out the index in the text. The original design was that one can write a dedicated renderer and position-to-index feature for each language etc., but nobody (including me) spent much time to utilize it (except for Japanese language). Another run to support more complete text handling, either in Squeak native or perhaps in the manner of calling external libraries could be useful. -- -- Yoshiki -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Tue Aug 4 23:14:28 2020 From: gettimothy at zoho.com (gettimothy) Date: Tue, 04 Aug 2020 19:14:28 -0400 Subject: [squeak-dev] Hubs delenda est and ESR's Cathedrak vs Bazzarr was: Re: Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <95f2a478caa34c96bbfa98f0917e6828@student.hpi.uni-potsdam.de> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <7F78D9C3-85B3-4514-B85B-9A010EF6B88F@gmx.de>, <173b42d84b7.c5e3ac7552071.3797801497954478016@zoho.com> <95f2a478caa34c96bbfa98f0917e6828@student.hpi.uni-potsdam.de> Message-ID: <173bbc13736.e2ebd5da131293.5174635750259225763@zoho.com> the immediate problem I have should be fixed when Europa returns from vacation and restarts the smalltalkhub server, according to Estaban on the pharo discord. What are the meta problems here? Hubs. Github, smalltalkhub, squeaksource A radicall solution based on that music sharing app bittorrent may be the way to go. It is ESR's Cathedral vs Bazzar problem. I need Squeak with XTreams , Seaside and PG3 for my work , all awesonme software packages, but the platforms are diverging where maintaining the trinity in my preferred platform is hard work. I would much prefer to torrent a working image than spend time reverse engineering a mundane problem. Torrents.smalltalk.org , or, really cool, peer to peer ala croquet. Cheers tty ---- On Tue, 04 Aug 2020 13:57:48 -0400 Tom.Beckmann at student.hpi.uni-potsdam.de wrote ---- Hey everyone, I just described our suggestion to approach a new bootstrapping process on Metacello's Github: https://github.com/Metacello/metacello/issues/524 We would appreciate it, if you could have a read through and see if you can identify potential problems or better ways to approach this, in particular also for the "Further Steps" part. Best, Tom ________________________________________ From: Squeak-dev on behalf of gettimothy via Squeak-dev Sent: Monday, August 3, 2020 1:55:48 PM To: squeak-dev at lists.squeakfoundation.org Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye Thanks all Are there steps I should be taking to help facilitate this? Thx ---- On Mon, 03 Aug 2020 06:49:47 -0400 Das.Linux at gmx.de wrote ---- > On 03.08.2020, at 10:13, Marcel Taeumel > wrote: > > Hi all! > > I think that Tom (tobe) had the idea to publish bootstrap MCZs via Metacello's GitHub releases page since it is very easy to point Monti(!)cello to such an HTML page to fetch downloadable content. In that case, we can put them on files.squeak.org, too … -t > > Best, > Marcel >> Am 02.08.2020 22:13:18 schrieb Jakob Reschke >: >> >> Probably related thread: >> http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html >> >> Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev >> : >> > >> > Hi folks, >> > >> > This probably holds for 5.3 install too. >> > >> > In the preferences wizard, the extras stuff, the Install Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" >> > >> > iirc, from the pharo discord, SmalltalkHub is going away. >> > >> > You will probably need a different repo. >> > >> > cordially, >> > >> > tty >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From digit at sonic.net Wed Aug 5 01:10:19 2020 From: digit at sonic.net (Tim Johnson) Date: Tue, 4 Aug 2020 18:10:19 -0700 Subject: [squeak-dev] Hubs delenda est and ESR's Cathedrak vs Bazzarr was: Re: Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <173bbc13736.e2ebd5da131293.5174635750259225763@zoho.com> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <7F78D9C3-85B3-4514-B85B-9A010EF6B88F@gmx.de>, <173b42d84b7.c5e3ac7552071.3797801497954478016@zoho.com> <95f2a478caa34c96bbfa98f0917e6828@student.hpi.uni-potsdam.de> <173bbc13736.e2ebd5da131293.5174635750259225763@zoho.com> Message-ID: <0F15797C-A26B-4A68-B1BA-C22262AE5D1A@sonic.net> Hi Timothy, The Internet Archive automatically offers BitTorrent for all of its items. And anyone can create an archive.org account and begin uploading items. Each item can be modified by its owner (uploaded, metadata changed) via the Internet Archive APIs: https://archive.org/services/docs/api/ http://blog.archive.org/developers/ The best example of these APIs in practice is the Python tool: https://github.com/jjjake/internetarchive (I used to work there and helped with some of the testing & debugging of this tool, actually.) I've sometimes dreamed of using Internet Archive items as Monticello repos, which would be writable by their owner but read-only to the rest of the world. It could serve as a good place for cold storage. I know Tigerbrew (a fork of Homebrew, a macOS package manager) uses Internet Archive in this way: https://archive.org/download/tigerbrew I started writing an Internet Archive client in Squeak a few years ago. At Camp Smalltalk last year I released what I had, though very unpolished and in need of better packaging for a proper release: https://github.com/tcj/craggyaloofness It's only capable of reading & downloading, not writing or modifying, items (though the API and Python tool do offer that capability). Nonetheless, it's fun (in my opinion) to be able to show the Byte magazine cover via a one-liner: (IAItem named: 'byte-magazine-1981-08' ) displayItemTileJpeg The way I imagined using Internet Archive for long-term storage of .mcz files would involve any interested developer creating an archive.org account and then uploading some file to create an item. That item would become the repo. Then, additional files could be uploaded to the item either through the archive.org web site, the API, the Python tool, or a nonexistent Monticello repository adapter. :) The developer could share the item name as the repo, and Monticello could read from it. Just dreaming aloud. Best, a Tim On Aug 4, 2020, at 4:14 PM, gettimothy via Squeak-dev wrote: > the immediate problem I have should be fixed when Europa returns > from vacation and restarts the smalltalkhub server, according to > Estaban on the pharo discord. > > What are the meta problems here? Hubs. > > Github, smalltalkhub, squeaksource > > > > A radicall solution based on that music sharing app bittorrent may > be the way to go. > > > > > It is ESR's Cathedral vs Bazzar problem. > > > I need Squeak with XTreams , Seaside and PG3 for my work , all > awesonme software packages, but the platforms are diverging where > maintaining the trinity in my preferred platform is hard work. > > I would much prefer to torrent a working image than spend time > reverse engineering a mundane problem. > > > > Torrents.smalltalk.org , or, really cool, peer to peer ala croquet. > > Cheers > > tty > > > > > > > > > > > > > > > > > > ---- On Tue, 04 Aug 2020 13:57:48 -0400 Tom.Beckmann at student.hpi.uni-potsdam.de > wrote ---- > > Hey everyone, > > I just described our suggestion to approach a new bootstrapping > process on Metacello's Github: https://github.com/Metacello/metacello/issues/524 > > We would appreciate it, if you could have a read through and see if > you can identify potential problems or better ways to approach this, > in particular also for the "Further Steps" part. > > Best, > Tom > ________________________________________ > From: Squeak-dev on > behalf of gettimothy via Squeak-dev > > Sent: Monday, August 3, 2020 1:55:48 PM > To: squeak-dev at lists.squeakfoundation.org > Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional > stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due > to smaltalkhub be bye-bye > > Thanks all > > > Are there steps I should be taking to help facilitate this? > > > > Thx > > > ---- On Mon, 03 Aug 2020 06:49:47 -0400 Das.Linux at gmx.de wrote ---- > > > > On 03.08.2020, at 10:13, Marcel Taeumel >> wrote: > > > > Hi all! > > > > I think that Tom (tobe) had the idea to publish bootstrap MCZs via > Metacello's GitHub releases page since it is very easy to point > Monti(!)cello to such an HTML page to fetch downloadable content. > > In that case, we can put them on files.squeak.org, too … > -t > > > > Best, > > Marcel > >> Am 02.08.2020 22:13:18 schrieb Jakob Reschke >: > >> > >> Probably related thread: > >> http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html > >> > >> Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev > >> : > >> > > >> > Hi folks, > >> > > >> > This probably holds for 5.3 install too. > >> > > >> > In the preferences wizard, the extras stuff, the Install > Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main > " > >> > > >> > iirc, from the pharo discord, SmalltalkHub is going away. > >> > > >> > You will probably need a different repo. > >> > > >> > cordially, > >> > > >> > tty > >> > > >> > > >> > > > > > > > > From forums.jakob at resfarm.de Wed Aug 5 06:49:01 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Wed, 5 Aug 2020 08:49:01 +0200 Subject: [squeak-dev] Hubs delenda est and ESR's Cathedrak vs Bazzarr was: Re: Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <173bbc13736.e2ebd5da131293.5174635750259225763@zoho.com> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <7F78D9C3-85B3-4514-B85B-9A010EF6B88F@gmx.de> <173b42d84b7.c5e3ac7552071.3797801497954478016@zoho.com> <95f2a478caa34c96bbfa98f0917e6828@student.hpi.uni-potsdam.de> <173bbc13736.e2ebd5da131293.5174635750259225763@zoho.com> Message-ID: Hi Timothy, I'm not sure whether I understand your fundamental problem right. Is it that each package is hosted and maintained in only one central location? Or is it too burdensome to remember or somehow deal with the multiple locations where they are stored? For the git-based packages, they can be easily mirrored to any other Git server, even a private one. Then next to GitHub, the packages could be on Bitbucket, Gitlab, and whatever. It would also be possible to set up a read-only Git server on squeak.org and mirror some important packages there. If there were more Monticello server providers out there, one could also mirror versions among these. With Personal Squeaksource you could run your own. Or maybe even the package-cache is enough. Or mirror them as Git repositories (converters exist nowadays). Note that Git can also be used for ad-hoc user to user sharing: https://git-scm.com/docs/git-daemon But it is mostly impractical if you are not on the same LAN as the one peer you are trying to synchronize with. (How to know the other person's Git address?) Now in reference to your Bittorrent analogy, you would still need a single address (a seed) to identify what you want to get. It would be used to derive a list of the mirrors/providers, which the client could contact. If one of them is down, another could be tried. Is that what you had in mind? For true peer-to-peer as in sharing without download hubs, I am afraid the Smalltalk community might be too small and the interests of their members too spread out to work reliably (i. e. too few people would offer a particular version of a package to the network). For popular things like Metacello, it might work, but the absolute number of people is still not great (though I'd like to be proven otherwise). If it was about the cognitive overhead of dealing with diverse locations, just put up the install scripts on SqueakMap if they are not already there. The scripts could also have a list of mirrors to contact if the prime location is down. Or put appropriate Metacello configurations/baselines in some central place such as http://squeaksource.com/MetacelloRepository/, your own GitHub repository, or, again, SqueakMap. Kind regards, Jakob Am Mi., 5. Aug. 2020 um 01:14 Uhr schrieb gettimothy via Squeak-dev : > > the immediate problem I have should be fixed when Europa returns from vacation and restarts the smalltalkhub server, according to Estaban on the pharo discord. > > What are the meta problems here? Hubs. > > Github, smalltalkhub, squeaksource > > > > A radicall solution based on that music sharing app bittorrent may be the way to go. > > > > > It is ESR's Cathedral vs Bazzar problem. > > > I need Squeak with XTreams , Seaside and PG3 for my work , all awesonme software packages, but the platforms are diverging where maintaining the trinity in my preferred platform is hard work. > > I would much prefer to torrent a working image than spend time reverse engineering a mundane problem. > > > > Torrents.smalltalk.org , or, really cool, peer to peer ala croquet. > > Cheers > > tty > > > > > > > > > > > > > > > > > > ---- On Tue, 04 Aug 2020 13:57:48 -0400 Tom.Beckmann at student.hpi.uni-potsdam.de wrote ---- > > Hey everyone, > > I just described our suggestion to approach a new bootstrapping process on Metacello's Github: https://github.com/Metacello/metacello/issues/524 > > We would appreciate it, if you could have a read through and see if you can identify potential problems or better ways to approach this, in particular also for the "Further Steps" part. > > Best, > Tom > ________________________________________ > From: Squeak-dev on behalf of gettimothy via Squeak-dev > Sent: Monday, August 3, 2020 1:55:48 PM > To: squeak-dev at lists.squeakfoundation.org > Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye > > Thanks all > > > Are there steps I should be taking to help facilitate this? > > > > Thx > > > ---- On Mon, 03 Aug 2020 06:49:47 -0400 Das.Linux at gmx.de wrote ---- > > > > On 03.08.2020, at 10:13, Marcel Taeumel > wrote: > > > > Hi all! > > > > I think that Tom (tobe) had the idea to publish bootstrap MCZs via Metacello's GitHub releases page since it is very easy to point Monti(!)cello to such an HTML page to fetch downloadable content. > > In that case, we can put them on files.squeak.org, too … > -t > > > > Best, > > Marcel > >> Am 02.08.2020 22:13:18 schrieb Jakob Reschke >: > >> > >> Probably related thread: > >> http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html > >> > >> Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev > >> : > >> > > >> > Hi folks, > >> > > >> > This probably holds for 5.3 install too. > >> > > >> > In the preferences wizard, the extras stuff, the Install Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" > >> > > >> > iirc, from the pharo discord, SmalltalkHub is going away. > >> > > >> > You will probably need a different repo. > >> > > >> > cordially, > >> > > >> > tty > >> > > >> > > >> > > > > > > > > From Tom.Beckmann at student.hpi.uni-potsdam.de Wed Aug 5 12:11:36 2020 From: Tom.Beckmann at student.hpi.uni-potsdam.de (Beckmann, Tom) Date: Wed, 5 Aug 2020 12:11:36 +0000 Subject: [squeak-dev] TrueTypeFont and Unicode Characters In-Reply-To: References: <2791C8A5-B675-4EAF-BF94-58D1D3B2AB2F@gmx.de> , Message-ID: Hi Eric, I recently played around with FreeType and ended up with this: https://github.com/tom95/sqfreetypefont It was developed for Linux and may work on Mac. The version of FreeType that you can get for Windows is, however, not compatible it appears. Note that if the font you're using also makes use of ligatures this may still not help you, as a library like HarfBuzz is required for the shaping process. The lookup is also optimized for characters in the ASCII range and otherwise uses a Dictionary, so it may be worth changing this if rendering turns out to be slow for large bodies of text outside the ASCII range. If you do try out the FreeTypeFont and run into any problems, I'm happy to assist via the Github issues of the project. Best, Tom ________________________________________ From: Squeak-dev on behalf of Yoshiki Ohshima Sent: Tuesday, August 4, 2020 11:24:08 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] TrueTypeFont and Unicode Characters On Tue, Aug 4, 2020 at 1:49 PM Eric Gade > wrote: Hello all, I wanted to revisit this issue as I'm working on it again. Back in April, Tobias mentioned the following: I'm not sure we are actually loading all glyphs. Also note, that nothing in the font (like substitiution tables) are actually supported :/ sorry. It appears that the particular ancient fonts that I'm using -- and other ancient fonts whose codepoints are now part of the Unicode standard -- make use of substitution in order to access points beyond 65535 (a full unsigned 16 bits). I know this to be true for my particular Akkadian fonts because if I dig into the code I am able to render the glyphs that TTFontReader has parsed out of the file, but only if I modify the renderGlyph:height:fgColor:bgColor:depth: message to look in the Font description's table of glyphs (rather than the codepoint sparsetable, which is 65535 entries long and has no glyphs at all in it). Is there some deep reason not to support GSUB (substitution), aside from the complexity of ligatures? Right now if a TTF file has a GSUB entry it's not even being parsed out by TTFontReader. I'm really bumping around in the dark here, but I might be able to come up with something that at least permits the use of straight 1 to 1 substitutions. Any thoughts or ideas? I'm attaching a few screenshots that can give a better idea of what I've done just to get something to render properly. I created a modified version of renderGlyph: (etc, etc). It looks very cool! The major reason is historical; using TrueType for rendering text was added with the idea that it follows the Smalltalk-80's basic text handling, e.g. the text width is the sum of individual character width, and none has non-positive advance width, etc., etc. One of the reasons is that it is not about just rendering, but if the user points within the text on screen, it'd have to figure out the index in the text. The original design was that one can write a dedicated renderer and position-to-index feature for each language etc., but nobody (including me) spent much time to utilize it (except for Japanese language). Another run to support more complete text handling, either in Squeak native or perhaps in the manner of calling external libraries could be useful. -- -- Yoshiki From eric.gade at gmail.com Wed Aug 5 12:45:09 2020 From: eric.gade at gmail.com (Eric Gade) Date: Wed, 5 Aug 2020 08:45:09 -0400 Subject: [squeak-dev] TrueTypeFont and Unicode Characters In-Reply-To: References: <2791C8A5-B675-4EAF-BF94-58D1D3B2AB2F@gmx.de> Message-ID: > On Wed, Aug 5, 2020 at 8:11 AM Beckmann, Tom < > Tom.Beckmann at student.hpi.uni-potsdam.de> wrote: > >> Hi Eric, >> >> I recently played around with FreeType and ended up with this: >> https://github.com/tom95/sqfreetypefont >> It was developed for Linux and may work on Mac. The version of FreeType >> that you can get for Windows is, however, not compatible it appears. >> > This is excellent, thanks! I'm having an issue trying to install according to the instructions, but I'll post that as an issue over on Github instead of polluting this space. On Tue, Aug 4, 2020 at 5:24 PM Yoshiki Ohshima > wrote: > >> >> The major reason is historical; using TrueType for rendering text was >> added with the idea that it follows the Smalltalk-80's basic text handling, >> e.g. the text width is the sum of individual character width, and none has >> non-positive advance width, etc., etc. One of the reasons is that it is not >> about just rendering, but if the user points within the text on screen, >> it'd have to figure out the index in the text. >> >> The original design was that one can write a dedicated renderer and >> position-to-index feature for each language etc., but nobody (including me) >> spent much time to utilize it (except for Japanese language). Another run >> to support more complete text handling, either in Squeak native or perhaps >> in the manner of calling external libraries could be useful. >> > Thanks, Yoshiki. That all makes sense to me. I think the basic TTF stuff is actually in pretty good shape (aside from ligatures). The following is more an FYI in case anyone else stumbles on this issue. After further investigation it appears that my diagnosis was incorrect: my particular issue is not about GSUB or any additional fancy text-handling tables. It turns out that the `cmap` table platform ID 0 (unicode), which is one of the few that the current Squeak implementation handles, has been updated in the time since the library was written. Specifically, Unicode 2.0 now specifies characters whose codepoints are 32-bit values (see the Overview here ). There are different encoding table sub-formats for these scenarios, as well as other encoding strategies for dealing with points that fall outside the 16 bit range. My particular font seems to be using Format 4 . If you click that link you'll see how complex it is. I can't even say I understand what they are talking about there, and it would be complicated to implement. OpenType is complicated! -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Wed Aug 5 14:42:17 2020 From: builds at travis-ci.org (Travis CI) Date: Wed, 05 Aug 2020 14:42:17 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1783 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f2ac5495ca03_13f8c09c1dd04165343@travis-tasks-d89ccd695-g9cf8.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1783 Status: Errored Duration: 17 mins and 50 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/715170273?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Thu Aug 6 05:21:56 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 6 Aug 2020 05:21:56 0000 Subject: [squeak-dev] The Inbox: Installer-Core-tcj.440.mcz Message-ID: A new version of Installer-Core was added to project The Inbox: http://source.squeak.org/inbox/Installer-Core-tcj.440.mcz ==================== Summary ==================== Name: Installer-Core-tcj.440 Author: tcj Time: 5 August 2020, 10:21:54.954624 pm UUID: b6ac0eda-4db6-4313-b760-50dcdd1dc584 Ancestors: Installer-Core-mt.439 Be more tolerant of a partially-installed or mis-installed Metacello. =============== Diff against Installer-Core-mt.439 =============== Item was changed: ----- Method: Installer class>>ensureRecentMetacello (in category 'scripts') ----- ensureRecentMetacello "Copied and adapted from https://github.com/Metacello/metacello/blob/master/README.md" | metacello | ((Smalltalk classNamed: #WebClient) ifNil: [ false ] ifNotNil: [ :webClient | [ (webClient httpHead: 'https://github.com') isSuccess ] on: Error do: [ false ] ]) ifFalse: [ ^self inform: 'Could not connect to "https://github.com".\\You need an internet connection and SSL support\to install (or update) Metacello.\\Please fix those issues and try again.' translated withCRs ]. self isMetacelloInstalled ifFalse: [ "Prepare a clean environment for it." + Smalltalk globals removeKey: #Metacello ifAbsent: []. - Smalltalk globals removeKey: #Metacello. "Get the Metacello configuration (for Squeak users)" Installer gemsource project: 'metacello'; addPackage: 'ConfigurationOfMetacello'; install. "Bootstrap Metacello Preview, using mcz files (#'previewBootstrap' symbolic version" ((Smalltalk classNamed: #ConfigurationOfMetacello) project version: #'previewBootstrap') load]. metacello := Smalltalk classNamed: #Metacello. "Now load latest version of Metacello" metacello new baseline: 'Metacello'; repository: 'github://Metacello/metacello:master/repository'; get. metacello new baseline: 'Metacello'; repository: 'github://Metacello/metacello:master/repository'; load: #('default' 'Metacello-Help'). ! Item was changed: ----- Method: Installer class>>isMetacelloInstalled (in category 'scripts') ----- isMetacelloInstalled + "Squeak is shipped with the global #Metacello referring to lightweight MetacelloStub. After the first message is sent, the latest Metacello is installed, replacing the stub. + Be tolerant of a partially-installed Metacello." + ^ (Smalltalk includesKey: #Metacello) + and: [(Smalltalk at: #Metacello) ~= MetacelloStub]! - "Squeak is shipped with the global #Metacello referring to lightweight MetacelloStub. After the first message is sent, the latest Metacello is installed, replacing the stub." - ^ (Smalltalk at: #Metacello) ~= MetacelloStub! From digit at sonic.net Thu Aug 6 05:37:53 2020 From: digit at sonic.net (Tim Johnson) Date: Wed, 5 Aug 2020 22:37:53 -0700 Subject: [squeak-dev] The Inbox: Installer-Core-tcj.440.mcz In-Reply-To: References: Message-ID: <57DDB9A8-2659-4759-9BCE-1EE0FA2A1C6F@sonic.net> Upon further testing, this may still need further work to become worthwhile. Please don't adopt it as-is. Thanks, Tim On Aug 5, 2020, at 10:21 PM, commits at source.squeak.org wrote: > A new version of Installer-Core was added to project The Inbox: > http://source.squeak.org/inbox/Installer-Core-tcj.440.mcz > > ==================== Summary ==================== > > Name: Installer-Core-tcj.440 > Author: tcj > Time: 5 August 2020, 10:21:54.954624 pm > UUID: b6ac0eda-4db6-4313-b760-50dcdd1dc584 > Ancestors: Installer-Core-mt.439 > > Be more tolerant of a partially-installed or mis-installed Metacello. > > =============== Diff against Installer-Core-mt.439 =============== > > Item was changed: > ----- Method: Installer class>>ensureRecentMetacello (in category > 'scripts') ----- > ensureRecentMetacello > "Copied and adapted from https://github.com/Metacello/metacello/blob/master/README.md > " > > | metacello | > ((Smalltalk classNamed: #WebClient) > ifNil: [ false ] > ifNotNil: [ :webClient | > [ (webClient httpHead: 'https://github.com') isSuccess ] > on: Error > do: [ false ] ]) > ifFalse: [ ^self inform: 'Could not connect to "https:// > github.com".\\You need an internet connection and SSL support\to > install (or update) Metacello.\\Please fix those issues and try > again.' translated withCRs ]. > > self isMetacelloInstalled ifFalse: [ > "Prepare a clean environment for it." > + Smalltalk globals removeKey: #Metacello ifAbsent: []. > - Smalltalk globals removeKey: #Metacello. > "Get the Metacello configuration (for Squeak users)" > Installer gemsource > project: 'metacello'; > addPackage: 'ConfigurationOfMetacello'; > install. > > "Bootstrap Metacello Preview, using mcz files > (#'previewBootstrap' symbolic version" > ((Smalltalk classNamed: #ConfigurationOfMetacello) project > version: #'previewBootstrap') load]. > > metacello := Smalltalk classNamed: #Metacello. > > "Now load latest version of Metacello" > metacello new > baseline: 'Metacello'; > repository: 'github://Metacello/metacello:master/repository'; > get. > metacello new > baseline: 'Metacello'; > repository: 'github://Metacello/metacello:master/repository'; > load: #('default' 'Metacello-Help'). > ! > > Item was changed: > ----- Method: Installer class>>isMetacelloInstalled (in category > 'scripts') ----- > isMetacelloInstalled > + "Squeak is shipped with the global #Metacello referring to > lightweight MetacelloStub. After the first message is sent, the > latest Metacello is installed, replacing the stub. > + Be tolerant of a partially-installed Metacello." > + ^ (Smalltalk includesKey: #Metacello) > + and: [(Smalltalk at: #Metacello) ~= MetacelloStub]! > - "Squeak is shipped with the global #Metacello referring to > lightweight MetacelloStub. After the first message is sent, the > latest Metacello is installed, replacing the stub." > - ^ (Smalltalk at: #Metacello) ~= MetacelloStub! > > > From commits at source.squeak.org Thu Aug 6 08:09:42 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 6 Aug 2020 08:09:42 0000 Subject: [squeak-dev] The Trunk: Collections-mt.906.mcz Message-ID: Marcel Taeumel uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-mt.906.mcz ==================== Summary ==================== Name: Collections-mt.906 Author: mt Time: 6 August 2020, 10:09:38.701052 am UUID: 97d0d39c-6fe1-914b-bb0b-6a1b9a2b9715 Ancestors: Collections-eem.905 Adds shortcuts for remove/replace text attributes using a predicate. =============== Diff against Collections-eem.905 =============== Item was added: + ----- Method: Text>>removeAttributesThat: (in category 'converting') ----- + removeAttributesThat: removalBlock + "Enumerate all attributes in the receiver. Remove those passing removalBlock." + + self + removeAttributesThat: removalBlock + replaceAttributesThat: [:att | false] + by: nil.! Item was added: + ----- Method: Text>>replaceAttributesThat:by: (in category 'converting') ----- + replaceAttributesThat: replaceBlock by: convertBlock + "Enumerate all attributes in the receiver. Replace those passing replaceBlock after converting it through convertBlock." + + self + removeAttributesThat: [:att | false] + replaceAttributesThat: replaceBlock + by: convertBlock.! From builds at travis-ci.org Thu Aug 6 14:42:37 2020 From: builds at travis-ci.org (Travis CI) Date: Thu, 06 Aug 2020 14:42:37 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1784 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f2c16dcab98e_13fac83fb619c28801d@travis-tasks-5fc8d74f57-mzcpb.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1784 Status: Errored Duration: 17 mins and 33 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/715519334?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.gade at gmail.com Thu Aug 6 18:27:51 2020 From: eric.gade at gmail.com (Eric Gade) Date: Thu, 6 Aug 2020 14:27:51 -0400 Subject: [squeak-dev] PositionableStream >> #peekBack behavior Message-ID: Hello, What is the expected behavior for a stream that is at position 1 when you send #peekBack? Intuitively I'd expect to get the first element of the underlying collection as a response. But instead I am getting nil. Here is an example that is failing: ``` elem := #(1 2 3 4). stream := ReadStream on: elem. first := stream next. first = 1. back := stream peekBack. back = first. ``` The last message is currently responding false. In Pharo this returns true, so there are differences. The currently implementation of PositionableStream >> #peekBack is: ``` peekBack "Return the element at the previous position, without changing position. Use indirect messages in case self is a StandardFileStream." | element | self position = 0 ifTrue: [self errorCantGoBack]. self position = 1 ifTrue: [self position: 0. ^ nil]. self skip: -2. element := self next. self skip: 1. ^ element ``` I can see the nil being returned there explicitly, so that's "where it's happening." Should this be the case though? Thanks -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Thu Aug 6 19:51:50 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 6 Aug 2020 19:51:50 0000 Subject: [squeak-dev] The Trunk: Collections-eem.907.mcz Message-ID: Eliot Miranda uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-eem.907.mcz ==================== Summary ==================== Name: Collections-eem.907 Author: eem Time: 6 August 2020, 12:51:46.481296 pm UUID: 4ea594f7-b7bf-4d48-9e7e-2e7cb3af5e70 Ancestors: Collections-mt.906 2.7x faster ByteArray>>readHexFrom: =============== Diff against Collections-mt.906 =============== Item was changed: ----- Method: ByteArray>>readHexFrom: (in category 'initialize') ----- readHexFrom: aStream "Initialize the receiver from a hexadecimal string representation" + + 1 to: self size do: + [:i| | n v1 v2 | + n := aStream next asInteger. + v1 := n > 57 "$9 asInteger = 57" + ifTrue: + [n > 96 "$a asInteger 97" + ifTrue: [n - 87] + ifFalse: [n > 64 "$A asInteger = 65" + ifTrue: [n - 55] + ifFalse: [-1]]] + ifFalse: [n - 48]. "$0 asInteger = 48" + (v1 between: 0 and: 15) ifFalse: [^self error: 'Hex digit expected']. + n := aStream next asInteger. + v2 := n > 57 "$9 asInteger = 57" + ifTrue: + [n > 96 "$a asInteger 97" + ifTrue: [n - 87] + ifFalse: [n > 64 "$A asInteger = 65" + ifTrue: [n - 55] + ifFalse: [-1]]] + ifFalse: [n - 48]. "$0 asInteger = 48" + (v2 between: 0 and: 15) ifFalse: [^self error: 'Hex digit expected']. + self at: i put: (v1 bitShift: 4) + v2] + + "Proof that our filter selects only hexadecimal characters: + (0 to: 255) + select: + [:n| + (n > 57 + ifTrue: + [n > 96 + ifTrue: [n - 87] + ifFalse: [n > 64 + ifTrue: [n - 55] + ifFalse: [-1]]] + ifFalse: [n - 48]) between: 0 and: 15] + thenCollect: + [:n| Character value: n]"! - | map v ch value | - map := '0123456789abcdefABCDEF'. - 1 to: self size do:[:i| - ch := aStream next. - v := (map indexOf: ch) - 1. - ((v between: 0 and: 15) or: [((v:= v - 6) between: 0 and: 15)]) ifFalse:[^self error: 'Hex digit expected']. - value := v bitShift: 4. - ch := aStream next. - v := (map indexOf: ch) - 1. - ((v between: 0 and: 15) or: [((v:= v - 6) between: 0 and: 15)]) ifFalse:[^self error: 'Hex digit expected']. - value := value + v. - self at: i put: value. - ]. - ! From leves at caesar.elte.hu Thu Aug 6 23:43:06 2020 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Fri, 7 Aug 2020 01:43:06 +0200 (CEST) Subject: [squeak-dev] PositionableStream >> #peekBack behavior In-Reply-To: References: Message-ID: Hi Eric, On Thu, 6 Aug 2020, Eric Gade wrote: > Hello, > > What is the expected behavior for a stream that is at position 1 when you send #peekBack? Intuitively I'd expect to get the first element of the underlying collection as a response. But instead I am getting nil. >   > Here is an example that is failing: > ``` > elem := #(1 2 3 4). > stream := ReadStream on: elem. > first := stream next. > first = 1. > back := stream peekBack. > back = first. > ``` > The last message is currently responding false. In Pharo this returns true, so there are differences. > > The currently implementation of PositionableStream >> #peekBack is: > ``` > peekBack > "Return the element at the previous position, without changing position.  Use indirect messages in case self is a StandardFileStream." > > | element | > self position = 0 ifTrue: [self errorCantGoBack]. > self position = 1 ifTrue: [self position: 0.  ^ nil]. > self skip: -2. > element := self next. > self skip: 1. > ^ element > ``` > > I can see the nil being returned there explicitly, so that's "where it's happening." Should this be the case though? The previous, probably original implmenetation of #peekBack used to send #oldBack to the stream. IIRC #oldBack was based on the idea that the position of a stream is an index of a sequence where #next means +1 to that index while #back means -1 to that index. Following that logic, you have to #skip: -2 and send #next to get the element -1 to position. #oldBack has been removed but the behavior of #peekBack is presumably the same as it was before. Some ancient but now external code may rely on #peekBack but it's not very likely such code would work in the current Trunk. #peekBack has no real users in the Trunk only a test remembers what it used to do. So, I think it's a good time to change its behavior to be based on #back. Levente > > Thanks > > > -- > Eric > > From lewis at mail.msen.com Fri Aug 7 03:01:16 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Thu, 6 Aug 2020 23:01:16 -0400 Subject: [squeak-dev] DoItFirst updates (for command option handling early in Squeak image startUp processing) Message-ID: <20200807030116.GA78237@shell.msen.com> I have added a couple of enhancements to DoItFirst. The -noinit option disables file and directory initialization to force a bare minimum of startup initialization. The -debug option provides a debugger halt at the earliest feasible point in the startup processing. To install: (Installer ss project: 'DoItFirst') package: 'DoItFirst-System-Support'; install DoItFirst image arguments: -doit argumentlist "evaluate each argument as a doIt expression" -evaluate arg "evaluate arg, print result then exit" -filein filelist "file in each file named in fileList" -cwd path "set FileDirectory defaultDirectory to path prior to evaluating other options" -debug "enter a debugger as soon as possible in the startUp processing" -noinit "mimimal initiialization, suppress file and directory startUp processing when evaluating options" -help "print this message" To make this work, call DoItFirst reevaluateDebug from Delay class>>startUp and call DoItFirst reevaluateCwd from FileDirectory class>>startUp Dave From builds at travis-ci.org Fri Aug 7 14:43:03 2020 From: builds at travis-ci.org (Travis CI) Date: Fri, 07 Aug 2020 14:43:03 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1785 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f2d6876f3bde_13f9f26cd1a0414516c@travis-tasks-5dd6ff4f47-gcpj6.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1785 Status: Errored Duration: 17 mins and 30 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/715856958?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.gade at gmail.com Fri Aug 7 21:32:05 2020 From: eric.gade at gmail.com (Eric Gade) Date: Fri, 7 Aug 2020 17:32:05 -0400 Subject: [squeak-dev] PositionableStream >> #peekBack behavior In-Reply-To: References: Message-ID: On Thu, Aug 6, 2020 at 7:45 PM Levente Uzonyi wrote: > So, I think it's a good time to change its behavior to be based on #back. > > > Levente > Ok I have the change (along with a few new tests) made and ready to go. I have never contributed to Squeak before. I am trying to follow these instructions from the wiki . I don't have a lot of experience here with Monticello and changesets, however. Right now my "changes" are across two different packages (Streams and Tests-Streams). Do I "save" these commits separately, or is there some way to have them both be in one commit? Thanks. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From leves at caesar.elte.hu Fri Aug 7 23:52:17 2020 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sat, 8 Aug 2020 01:52:17 +0200 (CEST) Subject: [squeak-dev] PositionableStream >> #peekBack behavior In-Reply-To: References: Message-ID: Hi Eric, On Fri, 7 Aug 2020, Eric Gade wrote: > > > On Thu, Aug 6, 2020 at 7:45 PM Levente Uzonyi wrote: >   > So, I think it's a good time to change its behavior to be based on #back. > > > Levente > > > Ok I have the change (along with a few new tests) made and ready to go. I have never contributed to Squeak before. I am trying to follow these instructions from the wiki. > I don't have a lot of experience here with Monticello and changesets, however. Right now my "changes" are across two different packages (Streams and Tests-Streams). Do I "save" these commits separately, or is there some way > to have them both be in one commit? It should be two commits, since commits are per package in Monticello. But, we don't have any packages named Streams or Test-Streams in Squeak. ReadStream is in the Collections package while ReadStreamTest is in the CollectionsTests package. Are you sure Streams and Tests-Streams are the names of the packages in your image? Levente > > Thanks. > -- > Eric > > From lewis at mail.msen.com Fri Aug 7 23:57:45 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 7 Aug 2020 19:57:45 -0400 Subject: [squeak-dev] PositionableStream >> #peekBack behavior In-Reply-To: References: Message-ID: <20200807235745.GA87423@shell.msen.com> On Sat, Aug 08, 2020 at 01:52:17AM +0200, Levente Uzonyi wrote: > Hi Eric, > > On Fri, 7 Aug 2020, Eric Gade wrote: > > > > > > >On Thu, Aug 6, 2020 at 7:45 PM Levente Uzonyi wrote: > >?? > > So, I think it's a good time to change its behavior to be based on > > #back. > > > > > > Levente > > > > > >Ok I have the change (along with a few new tests) made and ready to go. I > >have never contributed to Squeak before. I am trying to follow these > >instructions from the wiki. > >I don't have a lot of experience here with Monticello and changesets, > >however. Right now my "changes" are across two different packages (Streams > >and Tests-Streams). Do I "save" these commits separately, or is there some > >way > >to have them both be in one commit? > > It should be two commits, since commits are per package in Monticello. > But, we don't have any packages named Streams or Test-Streams in Squeak. > ReadStream is in the Collections package while ReadStreamTest is in the > CollectionsTests package. > Are you sure Streams and Tests-Streams are the names of the packages in > your image? > Hi Eric, To add to what Levente says, Usually what you would want to do is save your changes using an existing package. For example, if you have some changes to class PositionableStream, that class is part of the 'Collections-Streams' category in a system browser, and when you look at the packages in a Monticello browser, this category is part of the 'Collections' package (this is all just based on naming conventions). If your image is up to date with the trunk update stream, then your image will be using Collections-eem.907.mcz from the trunk repository, and the changes that you have made in your image would be relative to that MCZ version. When you save your changes to the inbox, you would be saving a new version called (probably) collections-EG.908.mcz. You will save your tests separately, probably in the 'CollectionsTests' package. It is fine to have the two separate, although sometimes it is helpful to add something in the commit comments along the lines of "these tests go with those changes" or "these updates in Collections make the tests in CollectionsTests pass" just to make the connection. Don't worry about getting this perfect (especially the first time!). Even if there is a mistake it is usually easy for people to figure out what the changes were and merge them at a later time. HTH, Dave From leves at caesar.elte.hu Sat Aug 8 00:07:10 2020 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sat, 8 Aug 2020 02:07:10 +0200 (CEST) Subject: [squeak-dev] The Trunk: Collections-eem.907.mcz In-Reply-To: References: Message-ID: Hi Eliot, If performance matters, I've got two alternative implementations. Both are about 1.2x faster than yours and are based on lookup tables. The first one uses #digitValue which uses Character's "built-in" DigitValues table: readHexFrom: aStream "Initialize the receiver from a hexadecimal string representation" 1 to: self size do: [ :i | | c v1 v2 | ((c := aStream next) asInteger > 102 "$f asInteger" or: [ (v1 := c digitValue) < 0 or: [ v1 > 15 or: [ (c := aStream next) asInteger > 102 "$f asInteger" or: [ (v2 := c digitValue) < 0 or: [ v2 > 15 ] ] ] ] ]) ifTrue: [ ^self error: 'Hex digit expected' ]. self at: i put: (v1 bitShift: 4) + v2 ] The second one uses a non-minimal perfect hash table with an extremely simple hash function: readHexFrom: aStream "Initialize the receiver from a hexadecimal string representation" | keys values | keys := #[0 65 66 67 68 69 70 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 97 98 99 100 101 102 0 0 0 0 0 0 0 0 0 48 49 50 51 52 53 54 55 56 57 0 0 0 0 0 0]. values := #[0 10 11 12 13 14 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 11 12 13 14 15 0 0 0 0 0 0 0 0 0 0 1 2 3 4 5 6 7 8 9 0 0 0 0 0 0]. 1 to: self size do: [ :i | | c index v1 v2 | c := aStream next asInteger. index := (c bitAnd: 63) + 1. (keys at: index) = c ifFalse: [ ^self error: 'Hex digit expected' ]. v1 := values at: index. c := aStream next asInteger. index := (c bitAnd: 63) + 1. (keys at: index) = c ifFalse: [ ^self error: 'Hex digit expected' ]. v2 := values at: index. self at: i put: (v1 bitShift: 4) + v2 ] Levente On Thu, 6 Aug 2020, commits at source.squeak.org wrote: > Eliot Miranda uploaded a new version of Collections to project The Trunk: > http://source.squeak.org/trunk/Collections-eem.907.mcz > > ==================== Summary ==================== > > Name: Collections-eem.907 > Author: eem > Time: 6 August 2020, 12:51:46.481296 pm > UUID: 4ea594f7-b7bf-4d48-9e7e-2e7cb3af5e70 > Ancestors: Collections-mt.906 > > 2.7x faster ByteArray>>readHexFrom: > > =============== Diff against Collections-mt.906 =============== > > Item was changed: > ----- Method: ByteArray>>readHexFrom: (in category 'initialize') ----- > readHexFrom: aStream > "Initialize the receiver from a hexadecimal string representation" > + > + 1 to: self size do: > + [:i| | n v1 v2 | > + n := aStream next asInteger. > + v1 := n > 57 "$9 asInteger = 57" > + ifTrue: > + [n > 96 "$a asInteger 97" > + ifTrue: [n - 87] > + ifFalse: [n > 64 "$A asInteger = 65" > + ifTrue: [n - 55] > + ifFalse: [-1]]] > + ifFalse: [n - 48]. "$0 asInteger = 48" > + (v1 between: 0 and: 15) ifFalse: [^self error: 'Hex digit expected']. > + n := aStream next asInteger. > + v2 := n > 57 "$9 asInteger = 57" > + ifTrue: > + [n > 96 "$a asInteger 97" > + ifTrue: [n - 87] > + ifFalse: [n > 64 "$A asInteger = 65" > + ifTrue: [n - 55] > + ifFalse: [-1]]] > + ifFalse: [n - 48]. "$0 asInteger = 48" > + (v2 between: 0 and: 15) ifFalse: [^self error: 'Hex digit expected']. > + self at: i put: (v1 bitShift: 4) + v2] > + > + "Proof that our filter selects only hexadecimal characters: > + (0 to: 255) > + select: > + [:n| > + (n > 57 > + ifTrue: > + [n > 96 > + ifTrue: [n - 87] > + ifFalse: [n > 64 > + ifTrue: [n - 55] > + ifFalse: [-1]]] > + ifFalse: [n - 48]) between: 0 and: 15] > + thenCollect: > + [:n| Character value: n]"! > - | map v ch value | > - map := '0123456789abcdefABCDEF'. > - 1 to: self size do:[:i| > - ch := aStream next. > - v := (map indexOf: ch) - 1. > - ((v between: 0 and: 15) or: [((v:= v - 6) between: 0 and: 15)]) ifFalse:[^self error: 'Hex digit expected']. > - value := v bitShift: 4. > - ch := aStream next. > - v := (map indexOf: ch) - 1. > - ((v between: 0 and: 15) or: [((v:= v - 6) between: 0 and: 15)]) ifFalse:[^self error: 'Hex digit expected']. > - value := value + v. > - self at: i put: value. > - ]. > - ! From commits at source.squeak.org Sat Aug 8 00:17:32 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sat, 8 Aug 2020 00:17:32 0000 Subject: [squeak-dev] The Inbox: Collections-EG.908.mcz Message-ID: A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-EG.908.mcz ==================== Summary ==================== Name: Collections-EG.908 Author: EG Time: 7 August 2020, 8:17:30.343164 pm UUID: d02855a8-a339-4f1d-bede-89a50f07892e Ancestors: Collections-eem.907 Changing behavior of #peekBack to (correctly) return first element of underlying collection when stream position is 1. =============== Diff against Collections-eem.907 =============== Item was changed: ----- Method: PositionableStream>>peekBack (in category 'accessing') ----- peekBack "Return the element at the previous position, without changing position. Use indirect messages in case self is a StandardFileStream." - | element | self position = 0 ifTrue: [self errorCantGoBack]. + element := self back. - self position = 1 ifTrue: [self position: 0. ^ nil]. - self skip: -2. - element := self next. self skip: 1. ^ element! From commits at source.squeak.org Sat Aug 8 00:18:25 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sat, 8 Aug 2020 00:18:25 0000 Subject: [squeak-dev] The Inbox: CollectionsTests-EG.342.mcz Message-ID: A new version of CollectionsTests was added to project The Inbox: http://source.squeak.org/inbox/CollectionsTests-EG.342.mcz ==================== Summary ==================== Name: CollectionsTests-EG.342 Author: EG Time: 7 August 2020, 8:18:24.376363 pm UUID: cd08c4bb-0a50-4a33-9fd1-96876f07f3e0 Ancestors: CollectionsTests-ul.341 Adding tests for the updated #peekBack behavior =============== Diff against CollectionsTests-ul.341 =============== Item was added: + ----- Method: ReadStreamTest>>testPeekBack (in category 'tests - back') ----- + testPeekBack + "Test the ability to peek backwards on the stream" + | stream | + stream := ReadStream on: 'abcd'. + stream skip: 2. + self assert: $b equals: stream peekBack! Item was added: + ----- Method: ReadStreamTest>>testPeekBackOnPosition1 (in category 'tests - back') ----- + testPeekBackOnPosition1 + "Ensure that #peekBack works from position 1, + giving us the first element in the stream" + | stream | + stream := ReadStream on: 'abcde'. + stream skip: 1. + self assert: $a equals: stream peekBack! Item was added: + ----- Method: ReadStreamTest>>testPeekBackOnPositionZero (in category 'tests - back') ----- + testPeekBackOnPositionZero + "Ensure that we *cannot* peekBack on a stream + that is currently at the start (zero) position" + | stream | + stream := ReadStream on: 'abcd'. + self + should: [ stream peekBack ] + raise: Error! From lewis at mail.msen.com Sat Aug 8 01:32:56 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 7 Aug 2020 21:32:56 -0400 Subject: [squeak-dev] The Inbox: Collections-EG.908.mcz In-Reply-To: References: Message-ID: <20200808013256.GA99520@shell.msen.com> The new tests and fix for PositionableStream look good, but there is a failure now in RWBinaryOrTextStreamTest>>testPeekBack. Dave On Sat, Aug 08, 2020 at 12:17:32AM +0000, commits at source.squeak.org wrote: > A new version of Collections was added to project The Inbox: > http://source.squeak.org/inbox/Collections-EG.908.mcz > > ==================== Summary ==================== > > Name: Collections-EG.908 > Author: EG > Time: 7 August 2020, 8:17:30.343164 pm > UUID: d02855a8-a339-4f1d-bede-89a50f07892e > Ancestors: Collections-eem.907 > > Changing behavior of #peekBack to (correctly) return first element of underlying collection when stream position is 1. > > =============== Diff against Collections-eem.907 =============== > > Item was changed: > ----- Method: PositionableStream>>peekBack (in category 'accessing') ----- > peekBack > "Return the element at the previous position, without changing position. Use indirect messages in case self is a StandardFileStream." > - > | element | > self position = 0 ifTrue: [self errorCantGoBack]. > + element := self back. > - self position = 1 ifTrue: [self position: 0. ^ nil]. > - self skip: -2. > - element := self next. > self skip: 1. > ^ element! > > From lewis at mail.msen.com Sat Aug 8 02:14:11 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Fri, 7 Aug 2020 22:14:11 -0400 Subject: [squeak-dev] The Inbox: Collections-EG.908.mcz In-Reply-To: <20200808013256.GA99520@shell.msen.com> References: <20200808013256.GA99520@shell.msen.com> Message-ID: <20200808021411.GA7672@shell.msen.com> Actually, I think that the new ReadStreamTest>>testPeekBack is not in agreement with the existing RWBinaryOrTextSteamTest>>testPeekBack. The peekBack method was not in Squeak 3.6, but it appears in Squeak 3.8. It is unused in the image, but it presumably is intended to support parsing things from a stream. If I understand correctly, peek means "show me the next element that has not yet been read from the stream", and peekBack means "show me the element before the one that was most recently read from the stream". So I expect that peekBack would mean to skip back 2 from the current position, not skip back 1. Dave On Fri, Aug 07, 2020 at 09:32:56PM -0400, David T. Lewis wrote: > The new tests and fix for PositionableStream look good, but there is a > failure now in RWBinaryOrTextStreamTest>>testPeekBack. > > Dave > > On Sat, Aug 08, 2020 at 12:17:32AM +0000, commits at source.squeak.org wrote: > > A new version of Collections was added to project The Inbox: > > http://source.squeak.org/inbox/Collections-EG.908.mcz > > > > ==================== Summary ==================== > > > > Name: Collections-EG.908 > > Author: EG > > Time: 7 August 2020, 8:17:30.343164 pm > > UUID: d02855a8-a339-4f1d-bede-89a50f07892e > > Ancestors: Collections-eem.907 > > > > Changing behavior of #peekBack to (correctly) return first element of underlying collection when stream position is 1. > > > > =============== Diff against Collections-eem.907 =============== > > > > Item was changed: > > ----- Method: PositionableStream>>peekBack (in category 'accessing') ----- > > peekBack > > "Return the element at the previous position, without changing position. Use indirect messages in case self is a StandardFileStream." > > - > > | element | > > self position = 0 ifTrue: [self errorCantGoBack]. > > + element := self back. > > - self position = 1 ifTrue: [self position: 0. ^ nil]. > > - self skip: -2. > > - element := self next. > > self skip: 1. > > ^ element! > > > > > From eric.gade at gmail.com Sat Aug 8 03:32:32 2020 From: eric.gade at gmail.com (Eric Gade) Date: Fri, 7 Aug 2020 23:32:32 -0400 Subject: [squeak-dev] The Inbox: Collections-EG.908.mcz In-Reply-To: <20200808021411.GA7672@shell.msen.com> References: <20200808013256.GA99520@shell.msen.com> <20200808021411.GA7672@shell.msen.com> Message-ID: Hi Dave, On Fri, Aug 7, 2020 at 10:14 PM David T. Lewis wrote: > Actually, I think that the new ReadStreamTest>>testPeekBack is not in > agreement with the existing RWBinaryOrTextSteamTest>>testPeekBack. > Looks like I got too excited and neglected to run the full test suite, apologies! > If I understand correctly, peek means "show me the next element that > has not yet been read from the stream", and peekBack means "show me the > element before the one that was most recently read from the stream". > So I expect that peekBack would mean to skip back 2 from the current > position, not skip back 1. > I see what you are saying and that makes sense to me. My thinking was that stream positions are always "between" the elements, and that a "peek forward" just means "grab the element but don't advance the position. In that case, peeking backward would do the same in the reverse direction: look one element back but not decrement the position. Because there are no senders I guess this isn't a big deal and we can trash the changes. It came up because I'm thinking of porting my refactor of GIFReadWriter and animated image parsing that I did for Pharo about a year ago. I use peekBack in a couple of places there but can definitely figure out another way to achieve the same result. (I'll save the GIF discussion for a later email because it's ... complicated). Thanks! > > Dave > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From builds at travis-ci.org Sat Aug 8 14:42:34 2020 From: builds at travis-ci.org (Travis CI) Date: Sat, 08 Aug 2020 14:42:34 +0000 Subject: [squeak-dev] [CRON] Passed: squeak-smalltalk/squeak-app#1786 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f2eb9d9aa56c_13fa68221d76c841bb@travis-tasks-74cd44dbc-qg4md.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1786 Status: Passed Duration: 16 mins and 45 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/716121833?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leves at caesar.elte.hu Sat Aug 8 16:32:56 2020 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sat, 8 Aug 2020 18:32:56 +0200 (CEST) Subject: [squeak-dev] The Inbox: Collections-EG.908.mcz In-Reply-To: <20200808021411.GA7672@shell.msen.com> References: <20200808013256.GA99520@shell.msen.com> <20200808021411.GA7672@shell.msen.com> Message-ID: Hi Dave, On Fri, 7 Aug 2020, David T. Lewis wrote: > Actually, I think that the new ReadStreamTest>>testPeekBack is not in > agreement with the existing RWBinaryOrTextSteamTest>>testPeekBack. > > The peekBack method was not in Squeak 3.6, but it appears in Squeak 3.8. > It is unused in the image, but it presumably is intended to support parsing > things from a stream. > > If I understand correctly, peek means "show me the next element that > has not yet been read from the stream", and peekBack means "show me the > element before the one that was most recently read from the stream". > So I expect that peekBack would mean to skip back 2 from the current > position, not skip back 1. Another interpretation of peek in the context of streams is to look around the current position without consuming any elements. #peek returns what #next would return without consuming any elements, and following the same logic, #peekBack is expected to return what #back would without affecting position. That interpretation is what Eric implemented. If we decide to stick with the previous implementation based on #oldBack, which does not make any practical sense to me, then we'll need another method to get the last read element, because #peekBack would return the penultimate one. Levente > > Dave > > On Fri, Aug 07, 2020 at 09:32:56PM -0400, David T. Lewis wrote: >> The new tests and fix for PositionableStream look good, but there is a >> failure now in RWBinaryOrTextStreamTest>>testPeekBack. >> >> Dave >> >> On Sat, Aug 08, 2020 at 12:17:32AM +0000, commits at source.squeak.org wrote: >> > A new version of Collections was added to project The Inbox: >> > http://source.squeak.org/inbox/Collections-EG.908.mcz >> > >> > ==================== Summary ==================== >> > >> > Name: Collections-EG.908 >> > Author: EG >> > Time: 7 August 2020, 8:17:30.343164 pm >> > UUID: d02855a8-a339-4f1d-bede-89a50f07892e >> > Ancestors: Collections-eem.907 >> > >> > Changing behavior of #peekBack to (correctly) return first element of underlying collection when stream position is 1. >> > >> > =============== Diff against Collections-eem.907 =============== >> > >> > Item was changed: >> > ----- Method: PositionableStream>>peekBack (in category 'accessing') ----- >> > peekBack >> > "Return the element at the previous position, without changing position. Use indirect messages in case self is a StandardFileStream." >> > - >> > | element | >> > self position = 0 ifTrue: [self errorCantGoBack]. >> > + element := self back. >> > - self position = 1 ifTrue: [self position: 0. ^ nil]. >> > - self skip: -2. >> > - element := self next. >> > self skip: 1. >> > ^ element! >> > >> > >> From leves at caesar.elte.hu Sat Aug 8 16:38:24 2020 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sat, 8 Aug 2020 18:38:24 +0200 (CEST) Subject: [squeak-dev] The Inbox: Collections-EG.908.mcz In-Reply-To: References: <20200808013256.GA99520@shell.msen.com> <20200808021411.GA7672@shell.msen.com> Message-ID: Hi Eric, On Fri, 7 Aug 2020, Eric Gade wrote: > Hi Dave, > > On Fri, Aug 7, 2020 at 10:14 PM David T. Lewis wrote: > Actually, I think that the new ReadStreamTest>>testPeekBack is not in > agreement with the existing RWBinaryOrTextSteamTest>>testPeekBack. > > > Looks like I got too excited and neglected to run the full test suite, apologies! >   > If I understand correctly, peek means "show me the next element that > has not yet been read from the stream", and peekBack means "show me the > element before the one that was most recently read from the stream". > So I expect that peekBack would mean to skip back 2 from the current > position, not skip back 1. > > > I see what you are saying and that makes sense to me. My thinking was that stream positions are always "between" the elements, and that a "peek forward" just means "grab the element but don't advance the position. In that > case, peeking backward would do the same in the reverse direction: look one element back but not decrement the position. > > Because there are no senders I guess this isn't a big deal and we can trash the changes. It came up because I'm thinking of porting my refactor of GIFReadWriter and animated image parsing that I did for Pharo about a year > ago. I use peekBack in a couple of places there but can definitely figure out another way to achieve the same result. (I'll save the GIF discussion for a later email because it's ... complicated). That sounds really cool. I hope it fixes the bug Karl reported early this year[1] (see the attached gif if you don't know). When I had a look at the code, I felt like rewriting it would be easier than fixing it. Now that I know the context of where you intend to use #peekBack, I suggest you shouldn't use it but rather store what #next returned in a variable. That should make a significant difference in performance if used in a tight loop. Levente [1] http://forum.world.st/BUG-GIFReadWriter-td5109760.html > > Thanks! >   > > Dave > > -- > Eric > > From eliot.miranda at gmail.com Sat Aug 8 16:47:56 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 8 Aug 2020 09:47:56 -0700 Subject: [squeak-dev] The Trunk: Collections-eem.907.mcz In-Reply-To: References: Message-ID: <9CB50989-95A4-4107-AB8A-7C40E4298D00@gmail.com> Hi Levente, > On Aug 7, 2020, at 5:07 PM, Levente Uzonyi wrote: > > Hi Eliot, > > If performance matters, I've got two alternative implementations. Performance isn’t that big a deal. But something told me that the indexOf: approach sux :-) > Both are about 1.2x faster than yours and are based on lookup tables. > The first one uses #digitValue which uses Character's "built-in" DigitValues table: > > readHexFrom: aStream > "Initialize the receiver from a hexadecimal string representation" > > 1 to: self size do: [ :i | > | c v1 v2 | > ((c := aStream next) asInteger > 102 "$f asInteger" > or: [ (v1 := c digitValue) < 0 > or: [ v1 > 15 > or: [ (c := aStream next) asInteger > 102 "$f asInteger" > or: [ (v2 := c digitValue) < 0 > or: [ v2 > 15 ] ] ] ] ]) > ifTrue: [ ^self error: 'Hex digit expected' ]. > self at: i put: (v1 bitShift: 4) + v2 ] When I tested this it was slower. I tested it on ByteArrays >= 256 bytes in length that were less than 50% zeros. So let’s not go this way. > > The second one uses a non-minimal perfect hash table with an extremely simple hash function: > > readHexFrom: aStream > "Initialize the receiver from a hexadecimal string representation" > > | keys values | > keys := #[0 65 66 67 68 69 70 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 97 98 99 100 101 102 0 0 0 0 0 0 0 0 0 48 49 50 51 52 53 54 55 56 57 0 0 0 0 0 0]. > values := #[0 10 11 12 13 14 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 11 12 13 14 15 0 0 0 0 0 0 0 0 0 0 1 2 3 4 5 6 7 8 9 0 0 0 0 0 0]. > 1 to: self size do: [ :i | > | c index v1 v2 | > c := aStream next asInteger. > index := (c bitAnd: 63) + 1. > (keys at: index) = c ifFalse: [ ^self error: 'Hex digit expected' ]. > v1 := values at: index. > c := aStream next asInteger. > index := (c bitAnd: 63) + 1. > (keys at: index) = c ifFalse: [ ^self error: 'Hex digit expected' ]. > v2 := values at: index. > self at: i put: (v1 bitShift: 4) + v2 ] That’s neat, I’ll remember the technique. But what we have is more straight forward. > Levente > >> On Thu, 6 Aug 2020, commits at source.squeak.org wrote: >> >> Eliot Miranda uploaded a new version of Collections to project The Trunk: >> http://source.squeak.org/trunk/Collections-eem.907.mcz >> >> ==================== Summary ==================== >> >> Name: Collections-eem.907 >> Author: eem >> Time: 6 August 2020, 12:51:46.481296 pm >> UUID: 4ea594f7-b7bf-4d48-9e7e-2e7cb3af5e70 >> Ancestors: Collections-mt.906 >> >> 2.7x faster ByteArray>>readHexFrom: >> >> =============== Diff against Collections-mt.906 =============== >> >> Item was changed: >> ----- Method: ByteArray>>readHexFrom: (in category 'initialize') ----- >> readHexFrom: aStream >> "Initialize the receiver from a hexadecimal string representation" >> + + 1 to: self size do: >> + [:i| | n v1 v2 | >> + n := aStream next asInteger. >> + v1 := n > 57 "$9 asInteger = 57" >> + ifTrue: >> + [n > 96 "$a asInteger 97" >> + ifTrue: [n - 87] >> + ifFalse: [n > 64 "$A asInteger = 65" >> + ifTrue: [n - 55] >> + ifFalse: [-1]]] + ifFalse: [n - 48]. "$0 asInteger = 48" >> + (v1 between: 0 and: 15) ifFalse: [^self error: 'Hex digit expected']. >> + n := aStream next asInteger. >> + v2 := n > 57 "$9 asInteger = 57" >> + ifTrue: >> + [n > 96 "$a asInteger 97" >> + ifTrue: [n - 87] >> + ifFalse: [n > 64 "$A asInteger = 65" >> + ifTrue: [n - 55] >> + ifFalse: [-1]]] >> + ifFalse: [n - 48]. "$0 asInteger = 48" >> + (v2 between: 0 and: 15) ifFalse: [^self error: 'Hex digit expected']. >> + self at: i put: (v1 bitShift: 4) + v2] >> + + "Proof that our filter selects only hexadecimal characters: >> + (0 to: 255) >> + select: >> + [:n| >> + (n > 57 >> + ifTrue: >> + [n > 96 + ifTrue: [n - 87] >> + ifFalse: [n > 64 >> + ifTrue: [n - 55] >> + ifFalse: [-1]]] >> + ifFalse: [n - 48]) between: 0 and: 15] >> + thenCollect: >> + [:n| Character value: n]"! >> - | map v ch value | >> - map := '0123456789abcdefABCDEF'. >> - 1 to: self size do:[:i| >> - ch := aStream next. >> - v := (map indexOf: ch) - 1. >> - ((v between: 0 and: 15) or: [((v:= v - 6) between: 0 and: 15)]) ifFalse:[^self error: 'Hex digit expected']. >> - value := v bitShift: 4. >> - ch := aStream next. >> - v := (map indexOf: ch) - 1. >> - ((v between: 0 and: 15) or: [((v:= v - 6) between: 0 and: 15)]) ifFalse:[^self error: 'Hex digit expected']. >> - value := value + v. >> - self at: i put: value. >> - ]. >> - ! > From lewis at mail.msen.com Sat Aug 8 18:40:01 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Sat, 8 Aug 2020 14:40:01 -0400 Subject: [squeak-dev] The Inbox: Collections-EG.908.mcz In-Reply-To: References: <20200808013256.GA99520@shell.msen.com> <20200808021411.GA7672@shell.msen.com> Message-ID: <20200808184001.GA97901@shell.msen.com> Hi Levente, On Sat, Aug 08, 2020 at 06:32:56PM +0200, Levente Uzonyi wrote: > Hi Dave, > > On Fri, 7 Aug 2020, David T. Lewis wrote: > > >Actually, I think that the new ReadStreamTest>>testPeekBack is not in > >agreement with the existing RWBinaryOrTextSteamTest>>testPeekBack. > > > >The peekBack method was not in Squeak 3.6, but it appears in Squeak 3.8. > >It is unused in the image, but it presumably is intended to support parsing > >things from a stream. > > > >If I understand correctly, peek means "show me the next element that > >has not yet been read from the stream", and peekBack means "show me the > >element before the one that was most recently read from the stream". > >So I expect that peekBack would mean to skip back 2 from the current > >position, not skip back 1. > > Another interpretation of peek in the context of streams is to look > around the current position without consuming any elements. > #peek returns what #next would return without consuming any elements, > and following the same logic, #peekBack is expected to return what #back > would without affecting position. > > That interpretation is what Eric implemented. When I first looked at it, I had the same interpretation as Eric and you. > > If we decide to stick with the previous implementation based on #oldBack, > which does not make any practical sense to me, then we'll need another > method to get the last read element, because #peekBack would return the > penultimate one. > You are right, it is inconsistent and confusing. But I wonder if there is any use case for a method that just answers the most recently read item. Sometimes I just look at Cuis when I want to find out how to do things right. Here is what Cuis does: 'ABCDEF' readStream next: 2; peekBack. ==> $B 'ABCDEF' readStream next: 2; back. ==> $B 'ABCDEF' readStream next: 2; oldPeekBack. ==> $A 'ABCDEF' readStream next: 1; peekBack. ==> $A 'ABCDEF' readStream next: 1; back. $A 'ABCDEF' readStream next: 1; oldPeekBack. ==> nil 'ABCDEF' readStream next: 0; peekBack. ==> Error: CantGoBack 'ABCDEF' readStream next: 0; back. ==> Error: CantGoBack 'ABCDEF' readStream next: 0; oldPeekBack. ==> Error: CantGoBack In Cuis, there are no senders of #peekBack, and one sender of #oldPeekBack (PositionableStream>>#backChunk). I think this is consistent with what you are recommending, so maybe we should just adopt the Cuis implmentations and update our tests accordingly. Note that the #oldPeekBack in Cuis is like our current #peekBack, and is still inconsistent with respect to whether it answers nil or raises an error, which still should be fixed. Dave > > Levente > > > > >Dave > > > >On Fri, Aug 07, 2020 at 09:32:56PM -0400, David T. Lewis wrote: > >>The new tests and fix for PositionableStream look good, but there is a > >>failure now in RWBinaryOrTextStreamTest>>testPeekBack. > >> > >>Dave > >> > >>On Sat, Aug 08, 2020 at 12:17:32AM +0000, commits at source.squeak.org wrote: > >>> A new version of Collections was added to project The Inbox: > >>> http://source.squeak.org/inbox/Collections-EG.908.mcz > >>> > >>> ==================== Summary ==================== > >>> > >>> Name: Collections-EG.908 > >>> Author: EG > >>> Time: 7 August 2020, 8:17:30.343164 pm > >>> UUID: d02855a8-a339-4f1d-bede-89a50f07892e > >>> Ancestors: Collections-eem.907 > >>> > >>> Changing behavior of #peekBack to (correctly) return first element of > >>underlying collection when stream position is 1. > >>> > >>> =============== Diff against Collections-eem.907 =============== > >>> > >>> Item was changed: > >>> ----- Method: PositionableStream>>peekBack (in category 'accessing') > >>----- > >>> peekBack > >>> "Return the element at the previous position, without changing > >>position. Use indirect messages in case self is a StandardFileStream." > >>> - > >>> | element | > >>> self position = 0 ifTrue: [self errorCantGoBack]. > >>> + element := self back. > >>> - self position = 1 ifTrue: [self position: 0. ^ nil]. > >>> - self skip: -2. > >>> - element := self next. > >>> self skip: 1. > >>> ^ element! > >>> > >>> > >> > From asqueaker at gmail.com Sat Aug 8 21:21:27 2020 From: asqueaker at gmail.com (Chris Muller) Date: Sat, 8 Aug 2020 16:21:27 -0500 Subject: [squeak-dev] PositionableStream >> #peekBack behavior In-Reply-To: References: Message-ID: > > > I can see the nil being returned there explicitly, so that's "where it's > happening." Should this be the case though? > > The previous, probably original implmenetation of #peekBack used to send > #oldBack to the stream. > IIRC #oldBack was based on the idea that the position of a stream is an > index of a sequence where #next means +1 to that index while #back means > -1 to that index. Following that logic, you have to #skip: -2 and send > #next to get the element -1 to position. > > #oldBack has been removed but the behavior of #peekBack is presumably the > same as it was before. Some ancient but now external code may rely on > #peekBack but it's not very likely such code would work in the current > Trunk. > #peekBack has no real users in the Trunk only a test remembers what it > used to do. > Given the above, and given that we have #next:, I ended up balancing that API with #peek:, and that again with #peekBack:. Since they all simply return a String, possibly empty, they dodge the question about nil vs. error entirely. So, I think it's a good time to change its behavior to be based on #back. > Without wanting to sound ungrateful for Eric's contribution (of which I look forward to more of), may we also consider the addition-by-subtraction opportunity? I mean, it kinda makes sense that there wouldn't, and won't, be any users of #peekBack. Maybe we should deprecate it. - Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Sat Aug 8 22:10:11 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Sat, 8 Aug 2020 18:10:11 -0400 Subject: [squeak-dev] PositionableStream >> #peekBack behavior In-Reply-To: References: Message-ID: <20200808221011.GA29615@shell.msen.com> On Sat, Aug 08, 2020 at 04:21:27PM -0500, Chris Muller wrote: > > > > > I can see the nil being returned there explicitly, so that's "where it's > > happening." Should this be the case though? > > > > The previous, probably original implmenetation of #peekBack used to send > > #oldBack to the stream. > > IIRC #oldBack was based on the idea that the position of a stream is an > > index of a sequence where #next means +1 to that index while #back means > > -1 to that index. Following that logic, you have to #skip: -2 and send > > #next to get the element -1 to position. > > > > #oldBack has been removed but the behavior of #peekBack is presumably the > > same as it was before. Some ancient but now external code may rely on > > #peekBack but it's not very likely such code would work in the current > > Trunk. > > #peekBack has no real users in the Trunk only a test remembers what it > > used to do. > > > > Given the above, and given that we have #next:, I ended up balancing that > API with #peek:, and that again with #peekBack:. Since they all simply > return a String, possibly empty, they dodge the question about nil vs. > error entirely. > > So, I think it's a good time to change its behavior to be based on #back. > > > > Without wanting to sound ungrateful for Eric's contribution (of which I > look forward to more of), may we also consider the addition-by-subtraction > opportunity? I mean, it kinda makes sense that there wouldn't, and won't, > be any users of #peekBack. Maybe we should deprecate it. > That's probably the best idea of all. As far as I can tell, #peekBack was used in PositionableStream>>#backChunk in the Squeak 3.8 era, but Levente's 3/22/2010 version of the method in trunk today eliminated the need for it. So given that nobody uses it and we don't know how it should work, +1 for deprecation. And +1 to looking forward to more contributions from Eric :-) Dave From eric.gade at gmail.com Sun Aug 9 02:55:11 2020 From: eric.gade at gmail.com (Eric Gade) Date: Sat, 8 Aug 2020 22:55:11 -0400 Subject: [squeak-dev] GIFs and the Color black Message-ID: Hi all, I've noticed that in the current implementation of GIFReadWriter, we cannot faithfully reproduce the color black when writing it and reading it back in. Quick note: before I rewrote large parts of the GIF stuff in Pharo a while back, it had the same implementation as Squeak. But both then and now, Pharo does not have the problem that I am describing. This leads me to believe that the problem is actually at some low level that I'm not equipped to understand. I'm hoping that the collective wisdom on this list might have some ideas. I'm thinking there's something going on with color mapping and Bitmaps (maybe color depths and conversions as well?) which I don't understand very well. On the other hand, I do have a good understanding of the GIF format since I worked on it. The LZW compression is a real nightmare, and even in my Pharo rewrite I had to keep the LZW encoding portions from the original implementation. The following code, when done in a workspace, will clearly demonstrate the issue: ``` blackForm := Form extent: 100 at 100. blackForm getCanvas fillColor: Color black. "Write to a bytestream" out := WriteStream on: ByteArray new. writer := GIFReadWriter on: out. writer nextPutImage: blackForm. writer close. "Read from the bytestream" in := ReadStream on: out contents. reader := GIFReadWriter on: in. result := reader nextImage. (result colorAt: 50 at 50) inspect. ``` The resulting color is not what we expect (Color black). It is (Color r: 0.0 g: 0.0 b: 0.004) Any ideas what's going on? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlramberg at gmail.com Sun Aug 9 07:24:42 2020 From: karlramberg at gmail.com (karl ramberg) Date: Sun, 9 Aug 2020 09:24:42 +0200 Subject: [squeak-dev] GIFs and the Color black In-Reply-To: References: Message-ID: I think Color r: 0.0 g: 0.0 b: 0.0 was/is reserved for transparency in forms with less than 32 bit depth, eg. no alpha channel Best, Karl On Sun, Aug 9, 2020 at 4:55 AM Eric Gade wrote: > Hi all, > > I've noticed that in the current implementation of GIFReadWriter, we > cannot faithfully reproduce the color black when writing it and reading it > back in. Quick note: before I rewrote large parts of the GIF stuff in Pharo > a while back, it had the same implementation as Squeak. But both then and > now, Pharo does not have the problem that I am describing. This leads me to > believe that the problem is actually at some low level that I'm not > equipped to understand. > > I'm hoping that the collective wisdom on this list might have some ideas. > I'm thinking there's something going on with color mapping and Bitmaps > (maybe color depths and conversions as well?) which I don't understand very > well. On the other hand, I do have a good understanding of the GIF format > since I worked on it. The LZW compression is a real nightmare, and even in > my Pharo rewrite I had to keep the LZW encoding portions from the original > implementation. > > The following code, when done in a workspace, will clearly demonstrate the > issue: > ``` > blackForm := Form extent: 100 at 100. > blackForm getCanvas fillColor: Color black. > > "Write to a bytestream" > out := WriteStream on: ByteArray new. > writer := GIFReadWriter on: out. > writer nextPutImage: blackForm. > writer close. > > "Read from the bytestream" > in := ReadStream on: out contents. > reader := GIFReadWriter on: in. > result := reader nextImage. > > (result colorAt: 50 at 50) inspect. > ``` > > The resulting color is not what we expect (Color black). It is (Color r: > 0.0 g: 0.0 b: 0.004) > > Any ideas what's going on? > > -- > Eric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Sun Aug 9 10:16:48 2020 From: gettimothy at zoho.com (gettimothy) Date: Sun, 09 Aug 2020 06:16:48 -0400 Subject: [squeak-dev] classVariableNames auto-sort is a nice touch. Message-ID: <173d2b908d4.1120dc4fe20882.4271457784227872257@zoho.com> Quick slow-clap for whoever added the auto-sort when a new classVariableName is added from a method prompt. very nice touch, thx -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.gade at gmail.com Sun Aug 9 16:46:28 2020 From: eric.gade at gmail.com (Eric Gade) Date: Sun, 9 Aug 2020 12:46:28 -0400 Subject: [squeak-dev] GIFs and the Color black In-Reply-To: References: Message-ID: On Sun, Aug 9, 2020 at 3:25 AM karl ramberg wrote: > I think Color r: 0.0 g: 0.0 b: 0.0 was/is reserved for transparency in > forms with less than 32 bit depth, eg. no alpha channel > > Best, > Karl > Hi Karl, Any idea how to find "where" this is set or happens? If I can track it down, I can compare to Pharo (which doesn't seem to have the issue I'm describing) and see how they deal with it. For anyone else interested in the problem / example I posted, I can supply a changeset that really breaks out the LZW/GIF compression and decompression stuff so that it's somewhat easier to step through. This is part of the work I did refactoring the current implementation, which is hard to follow. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Sun Aug 9 16:47:38 2020 From: tim at rowledge.org (tim Rowledge) Date: Sun, 9 Aug 2020 09:47:38 -0700 Subject: [squeak-dev] GIFs and the Color black In-Reply-To: References: Message-ID: <5951EBA0-927E-46F7-BAA6-24E8FC51D263@rowledge.org> > On 2020-08-09, at 12:24 AM, karl ramberg wrote: > > I think Color r: 0.0 g: 0.0 b: 0.0 was/is reserved for transparency in forms with less than 32 bit depth, eg. no alpha channel Yup. It was done that way a loooooooooong time ago for what seemed like good reasons at the time. Digging through the maillist archives probably more than 20 years would find the discussions. I suppose the question is whether it is really still a good idea, and if not, could we fix it? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim If you don't pay the exorcist do you get repossessed? From digit at sonic.net Sun Aug 9 17:15:17 2020 From: digit at sonic.net (Tim Johnson) Date: Sun, 09 Aug 2020 10:15:17 -0700 Subject: [squeak-dev] FileTree in Squeak 5.3 can't load Grease repo, but issue was fixed in 2016 Message-ID: <8f7661c55fa79ffb0c748ed78c60c685@sonic.net> Hi all, I filed an issue against FileTree[1] and spent some time crafting a solution, only to find that @krono had already crafted & submitted a fix in 2016: https://github.com/dalehenrich/filetree/commit/262b0288b113bca0b3aff1bee005d87916c0c1ff https://github.com/dalehenrich/filetree/commit/30628e0b646eede0823e05fab1c3511aa1c5e982 So: why isn't the fix loaded into a fresh Squeak 5.3 image after performing "Installer ensureRecentMetacello"? The two commits related to the fix seem to have been properly merged into the squeak4.3 dialect branch. Could it be that ConfigurationOfFileTree needs updating to include this commit? It seems the #stable version, 1.0.6.2, has a timestamp of 10/29/2014 12:48. It includes the following for Squeak: spec for: #'squeak' do: [ spec package: 'MonticelloFileTree-Core' with: 'MonticelloFileTree-Core.squeak43-dkh.169'; package: 'MonticelloFileTree-FileDirectory-Utilities' with: 'MonticelloFileTree-FileDirectory-Utilities.squeak43-dkh.12'. ]. Would the solution be to update this spec to a newer package version? Thanks, Tim [1] https://github.com/dalehenrich/filetree/issues/229 From leves at caesar.elte.hu Sun Aug 9 17:32:57 2020 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Sun, 9 Aug 2020 19:32:57 +0200 (CEST) Subject: [squeak-dev] The Trunk: Collections-eem.907.mcz In-Reply-To: <9CB50989-95A4-4107-AB8A-7C40E4298D00@gmail.com> References: <9CB50989-95A4-4107-AB8A-7C40E4298D00@gmail.com> Message-ID: Hi Eliot, On Sat, 8 Aug 2020, Eliot Miranda wrote: > Hi Levente, > > >> On Aug 7, 2020, at 5:07 PM, Levente Uzonyi wrote: >> >> Hi Eliot, >> >> If performance matters, I've got two alternative implementations. > > Performance isn’t that big a deal. But something told me that the indexOf: approach sux :-) > >> Both are about 1.2x faster than yours and are based on lookup tables. >> The first one uses #digitValue which uses Character's "built-in" DigitValues table: >> >> readHexFrom: aStream >> "Initialize the receiver from a hexadecimal string representation" >> >> 1 to: self size do: [ :i | >> | c v1 v2 | >> ((c := aStream next) asInteger > 102 "$f asInteger" >> or: [ (v1 := c digitValue) < 0 >> or: [ v1 > 15 >> or: [ (c := aStream next) asInteger > 102 "$f asInteger" >> or: [ (v2 := c digitValue) < 0>> or: [ v2 > 15 ] ] ] ] ]) >> ifTrue: [ ^self error: 'Hex digit expected' ]. >> self at: i put: (v1 bitShift: 4) + v2 ] > > When I tested this it was slower. I tested it on ByteArrays >= 256 bytes in length that were less than 50% zeros. So let’s not go this way. That seemed really surprising first, but the "less than 50% zeroes" gave it away. Your code takes different execution paths based on the input, and that has a surpisingly significant effect on performance. Here's the benchmark I used which generates uniformly distributed values with mixed lower and upper case characters. It shows the performance difference I wrote: | b r letters s stream | b := ByteArray new: 1000. r := Random seed: 36rSqueak. letters := ($0 to: $9), ($0 to: $9), ($a to: $f), ($A to: $F). s := (1 to: b size * 2) collect: [ :e | letters atRandom: r ] as: String. stream := s readStream. { [ stream reset. b readHexFrom: stream ] benchFor: 1 seconds. [ stream reset. b readHexFromVariant1: stream ] benchFor: 1 seconds. [ stream reset. b readHexFromVariant2: stream ] benchFor: 1 seconds } #( '16,700 per second. 59.7 microseconds per run. 0 % GC time.' '20,200 per second. 49.4 microseconds per run. 0 % GC time.' '20,100 per second. 49.8 microseconds per run. 0 % GC time.' ) However, if the input is restricted to 0-9 characters by using letters := $0 to: $9. in the above benchmark, the results become #( '22,700 per second. 44.2 microseconds per run. 0 % GC time.' '19,400 per second. 51.5 microseconds per run. 0 % GC time.' '19,500 per second. 51.3 microseconds per run. 0 % GC time.' ) with letters := ($0 to: $9), ($a to: $f). the results are #( '18,800 per second. 53.1 microseconds per run. 0 % GC time.' '21,200 per second. 47.2 microseconds per run. 0 % GC time.' '20,200 per second. 49.4 microseconds per run. 0 % GC time.' ) and with letters := $a to: $f. #( '22,600 per second. 44.3 microseconds per run. 0 % GC time.' '20,500 per second. 48.9 microseconds per run. 0 % GC time.' '20,000 per second. 50 microseconds per run. 0 % GC time.' ) So, the more characters are from a single range (0-9 or a-f or A-F), as it was probably the case with the data you benchmarked with, the faster your variant becomes. Levente > >> >> The second one uses a non-minimal perfect hash table with an extremely simple hash function: >> >> readHexFrom: aStream >> "Initialize the receiver from a hexadecimal string representation" >> >> | keys values | >> keys := #[0 65 66 67 68 69 70 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 97 98 99 100 101 102 0 0 0 0 0 0 0 0 0 48 49 50 51 52 53 54 55 56 57 0 0 0 0 0 0]. >> values := #[0 10 11 12 13 14 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 11 12 13 14 15 0 0 0 0 0 0 0 0 0 0 1 2 3 4 5 6 7 8 9 0 0 0 0 0 0]. >> 1 to: self size do: [ :i | >> | c index v1 v2 | >> c := aStream next asInteger. >> index := (c bitAnd: 63) + 1. >> (keys at: index) = c ifFalse: [ ^self error: 'Hex digit expected' ]. >> v1 := values at: index. >> c := aStream next asInteger. >> index := (c bitAnd: 63) + 1. >> (keys at: index) = c ifFalse: [ ^self error: 'Hex digit expected' ]. >> v2 := values at: index. >> self at: i put: (v1 bitShift: 4) + v2 ] > > That’s neat, I’ll remember the technique. But what we have is more straight forward. > >> Levente >> >>> On Thu, 6 Aug 2020, commits at source.squeak.org wrote: >>> >>> Eliot Miranda uploaded a new version of Collections to project The Trunk: >>> http://source.squeak.org/trunk/Collections-eem.907.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Collections-eem.907 >>> Author: eem >>> Time: 6 August 2020, 12:51:46.481296 pm >>> UUID: 4ea594f7-b7bf-4d48-9e7e-2e7cb3af5e70 >>> Ancestors: Collections-mt.906 >>> >>> 2.7x faster ByteArray>>readHexFrom: >>> >>> =============== Diff against Collections-mt.906 =============== >>> >>> Item was changed: >>> ----- Method: ByteArray>>readHexFrom: (in category 'initialize') ----- >>> readHexFrom: aStream >>> "Initialize the receiver from a hexadecimal string representation" >>> + + 1 to: self size do: >>> + [:i| | n v1 v2 | >>> + n := aStream next asInteger. >>> + v1 := n > 57 "$9 asInteger = 57" >>> + ifTrue: >>> + [n > 96 "$a asInteger 97" >>> + ifTrue: [n - 87] >>> + ifFalse: [n > 64 "$A asInteger = 65" >>> + ifTrue: [n - 55] >>> + ifFalse: [-1]]] + ifFalse: [n - 48]. "$0 asInteger = 48" >>> + (v1 between: 0 and: 15) ifFalse: [^self error: 'Hex digit expected']. >>> + n := aStream next asInteger. >>> + v2 := n > 57 "$9 asInteger = 57" >>> + ifTrue: >>> + [n > 96 "$a asInteger 97" >>> + ifTrue: [n - 87] >>> + ifFalse: [n > 64 "$A asInteger = 65" >>> + ifTrue: [n - 55] >>> + ifFalse: [-1]]] >>> + ifFalse: [n - 48]. "$0 asInteger = 48" >>> + (v2 between: 0 and: 15) ifFalse: [^self error: 'Hex digit expected']. >>> + self at: i put: (v1 bitShift: 4) + v2] >>> + + "Proof that our filter selects only hexadecimal characters: >>> + (0 to: 255) >>> + select: >>> + [:n| >>> + (n > 57 >>> + ifTrue: >>> + [n > 96 + ifTrue: [n - 87] >>> + ifFalse: [n > 64 >>> + ifTrue: [n - 55] >>> + ifFalse: [-1]]] >>> + ifFalse: [n - 48]) between: 0 and: 15] >>> + thenCollect: >>> + [:n| Character value: n]"! >>> - | map v ch value | >>> - map := '0123456789abcdefABCDEF'. >>> - 1 to: self size do:[:i| >>> - ch := aStream next. >>> - v := (map indexOf: ch) - 1. >>> - ((v between: 0 and: 15) or: [((v:= v - 6) between: 0 and: 15)]) ifFalse:[^self error: 'Hex digit expected']. >>> - value := v bitShift: 4. >>> - ch := aStream next. >>> - v := (map indexOf: ch) - 1. >>> - ((v between: 0 and: 15) or: [((v:= v - 6) between: 0 and: 15)]) ifFalse:[^self error: 'Hex digit expected']. >>> - value := value + v. >>> - self at: i put: value. >>> - ]. >>> - ! >> From karlramberg at gmail.com Sun Aug 9 20:13:13 2020 From: karlramberg at gmail.com (karl ramberg) Date: Sun, 9 Aug 2020 22:13:13 +0200 Subject: [squeak-dev] GIFs and the Color black In-Reply-To: <5951EBA0-927E-46F7-BAA6-24E8FC51D263@rowledge.org> References: <5951EBA0-927E-46F7-BAA6-24E8FC51D263@rowledge.org> Message-ID: Hi, See this thread: http://forum.world.st/Color-black-vs-Color-transparent-td4909167.html Best, Karl On Sun, Aug 9, 2020 at 6:47 PM tim Rowledge wrote: > > > > On 2020-08-09, at 12:24 AM, karl ramberg wrote: > > > > I think Color r: 0.0 g: 0.0 b: 0.0 was/is reserved for transparency in > forms with less than 32 bit depth, eg. no alpha channel > > Yup. It was done that way a loooooooooong time ago for what seemed like > good reasons at the time. Digging through the maillist archives probably > more than 20 years would find the discussions. > > I suppose the question is whether it is really still a good idea, and if > not, could we fix it? > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > If you don't pay the exorcist do you get repossessed? > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forums.jakob at resfarm.de Mon Aug 10 19:09:03 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Mon, 10 Aug 2020 21:09:03 +0200 Subject: [squeak-dev] Fwd: Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> Message-ID: Forwarding missing posts to the list with Timothy's approval. ---------- Forwarded message --------- Von: gettimothy Date: Sa., 8. Aug. 2020 um 19:48 Uhr Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye To: Jakob Reschke With Smalltalkhub back up, everthing is installing nicely. I can now focus on the Seaside compat between Squeak and Pharo. However, my concerns still hold, it is a bit wierd that a script on Gemstones depends on a script on SmalltalkHub. cheers! tty ---- On Sun, 02 Aug 2020 16:12:54 -0400 Jakob Reschke wrote ---- Probably related thread: http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev : > > Hi folks, > > This probably holds for 5.3 install too. > > In the preferences wizard, the extras stuff, the Install Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" > > iirc, from the pharo discord, SmalltalkHub is going away. > > You will probably need a different repo. > > cordially, > > tty > > From digit at sonic.net Tue Aug 11 15:20:17 2020 From: digit at sonic.net (Tim Johnson) Date: Tue, 11 Aug 2020 08:20:17 -0700 Subject: [squeak-dev] Fwd: Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> Message-ID: It was working for me as of this weekend also. If Timothy feels inspired, I could definitely use the help figuring out how to update the ConfigurationOfFileTree to use the 2016 commits from @krono as described in my recent post to the list. Without this 2016 fix, the Grease repo doesn't load in Squeak's Monticello Browser, so efforts to work on the Seaside compatibility with Squeak (a.k.a., Grease) likely won't be fruitful. I view this operation as rather complex, so could definitely use advice. I don't know if it's a question of asking Dale to cherry-pick these commits into the 'master' branch, or update the spec for Squeak, or both, or neither. It's also possible (*but unlikely*) that all of this has been done in /one/ repo, but that the 'Installer ensureRecentMetacello' is using some /other/ repo somewhere which contains an older spec or baseline missing these 2016 updates. Thanks, Another Tim On 2020-08-10 12:09, Jakob Reschke wrote: > Forwarding missing posts to the list with Timothy's approval. > > ---------- Forwarded message --------- > Von: gettimothy > Date: Sa., 8. Aug. 2020 um 19:48 Uhr > Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional > stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due > to smaltalkhub be bye-bye > To: Jakob Reschke > > > With Smalltalkhub back up, everthing is installing nicely. > > I can now focus on the Seaside compat between Squeak and Pharo. > > However, my concerns still hold, it is a bit wierd that a script on > Gemstones depends on a script on SmalltalkHub. > > > cheers! > > tty > > > ---- On Sun, 02 Aug 2020 16:12:54 -0400 Jakob Reschke > wrote ---- > > Probably related thread: > http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html > > Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev > : >> >> Hi folks, >> >> This probably holds for 5.3 install too. >> >> In the preferences wizard, the extras stuff, the Install Metacello ... >> hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" >> >> iirc, from the pharo discord, SmalltalkHub is going away. >> >> You will probably need a different repo. >> >> cordially, >> >> tty >> >> From dale.henrichs at gemtalksystems.com Tue Aug 11 16:08:38 2020 From: dale.henrichs at gemtalksystems.com (Dale Henrichs) Date: Tue, 11 Aug 2020 09:08:38 -0700 Subject: [squeak-dev] Fwd: Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> Message-ID: Tim, There is no master branch for filetree, the filetree project uses an branch per platform model, I started out trying to keep the common code on the master branch, but it proved to be too difficult, So each platform is pretty much independent ... If it would help, I've invited you to be a contributor to the filetree project so that you can do your own management of the squeak support. As you can imagine, filetree is one of the first github projects (using filetree):) and I made the platform per branch decision fairly early on and learned over time that it is not quite the right model to use ... and now it would be difficult to try to switch to a better model -  branch per release with conditional platform code, is my current favorite... I did see your issues, but I've been busy with working on some bugfixes aimed at an imminent release and haven't had the time to look at it in more detail ... things will be a little hectic for me over the next week or so, but hopefully will settle down for a bit, before the next wave hits:) Dale On 8/11/20 8:20 AM, Tim Johnson wrote: > It was working for me as of this weekend also. > > If Timothy feels inspired, I could definitely use the help figuring > out how to update the ConfigurationOfFileTree to use the 2016 commits > from @krono as described in my recent post to the list. > > Without this 2016 fix, the Grease repo doesn't load in Squeak's > Monticello Browser, so efforts to work on the Seaside compatibility > with Squeak (a.k.a., Grease) likely won't be fruitful. > > I view this operation as rather complex, so could definitely use > advice.  I don't know if it's a question of asking Dale to cherry-pick > these commits into the 'master' branch, or update the spec for Squeak, > or both, or neither.  It's also possible (*but unlikely*) that all of > this has been done in /one/ repo, but that the 'Installer > ensureRecentMetacello' is using some /other/ repo somewhere which > contains an older spec or baseline missing these 2016 updates. > > Thanks, > Another Tim > > > On 2020-08-10 12:09, Jakob Reschke wrote: >> Forwarding missing posts to the list with Timothy's approval. >> >> ---------- Forwarded message --------- >> Von: gettimothy >> Date: Sa., 8. Aug. 2020 um 19:48 Uhr >> Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional >> stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due >> to smaltalkhub be bye-bye >> To: Jakob Reschke >> >> >> With Smalltalkhub back up, everthing is installing nicely. >> >> I can now focus on the Seaside compat between Squeak and Pharo. >> >> However, my concerns still hold, it is a bit wierd that a script on >> Gemstones depends on a script on SmalltalkHub. >> >> >> cheers! >> >> tty >> >> >> ---- On Sun, 02 Aug 2020 16:12:54 -0400 Jakob Reschke >> wrote ---- >> >> Probably related thread: >> http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html >> >> >> Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev >> : >>> >>> Hi folks, >>> >>> This probably holds for 5.3 install too. >>> >>> In the preferences wizard, the extras stuff, the Install Metacello >>> ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" >>> >>> iirc, from the pharo discord, SmalltalkHub is going away. >>> >>> You will probably need a different repo. >>> >>> cordially, >>> >>> tty >>> >>> > From gettimothy at zoho.com Tue Aug 11 18:55:20 2020 From: gettimothy at zoho.com (gettimothy) Date: Tue, 11 Aug 2020 14:55:20 -0400 Subject: [squeak-dev] Fwd: Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> Message-ID: <173dee07d89.c59a898353484.3634821705452097787@zoho.com> Wow! Seaside compat is one of my "dabble in side projects" during downtime, so if this Filetree thing is a pre-req, then I will try. Be aware, my time is very limited for the side projects, but I will help as I can. cheers, ---- On Tue, 11 Aug 2020 11:20:17 -0400 Tim Johnson wrote ---- It was working for me as of this weekend also. If Timothy feels inspired, I could definitely use the help figuring out how to update the ConfigurationOfFileTree to use the 2016 commits from @krono as described in my recent post to the list. Without this 2016 fix, the Grease repo doesn't load in Squeak's Monticello Browser, so efforts to work on the Seaside compatibility with Squeak (a.k.a., Grease) likely won't be fruitful. I view this operation as rather complex, so could definitely use advice. I don't know if it's a question of asking Dale to cherry-pick these commits into the 'master' branch, or update the spec for Squeak, or both, or neither. It's also possible (*but unlikely*) that all of this has been done in /one/ repo, but that the 'Installer ensureRecentMetacello' is using some /other/ repo somewhere which contains an older spec or baseline missing these 2016 updates. Thanks, Another Tim On 2020-08-10 12:09, Jakob Reschke wrote: > Forwarding missing posts to the list with Timothy's approval. > > ---------- Forwarded message --------- > Von: gettimothy > Date: Sa., 8. Aug. 2020 um 19:48 Uhr > Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional > stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due > to smaltalkhub be bye-bye > To: Jakob Reschke > > > With Smalltalkhub back up, everthing is installing nicely. > > I can now focus on the Seaside compat between Squeak and Pharo. > > However, my concerns still hold, it is a bit wierd that a script on > Gemstones depends on a script on SmalltalkHub. > > > cheers! > > tty > > > ---- On Sun, 02 Aug 2020 16:12:54 -0400 Jakob Reschke > wrote ---- > > Probably related thread: > http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html > > Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev > : >> >> Hi folks, >> >> This probably holds for 5.3 install too. >> >> In the preferences wizard, the extras stuff, the Install Metacello ... >> hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" >> >> iirc, from the pharo discord, SmalltalkHub is going away. >> >> You will probably need a different repo. >> >> cordially, >> >> tty >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Tue Aug 11 18:59:31 2020 From: gettimothy at zoho.com (gettimothy) Date: Tue, 11 Aug 2020 14:59:31 -0400 Subject: [squeak-dev] Fwd: Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> Message-ID: <173dee44f1f.1176e3bd753529.3060846262879091473@zoho.com> " As you can imagine, filetree is one of the first github projects (using filetree):) and I made the platform per branch decision fairly early on and learned over time that it is not quite the right model to use ... and now it would be difficult to try to switch to a better model -  branch per release with conditional platform code, is my current favorite..." If "branch per release with conditional platform code.." is the model for the Seaside compat, shouldn't we bite the bullet and make Filetree the same? If "branch per release with conditional platform code.." is NOT the model for the Seaside compat, somebody please inform me.  thx. ​ ---- On Tue, 11 Aug 2020 12:08:38 -0400 Dale Henrichs wrote ---- Tim, There is no master branch for filetree, the filetree project uses an branch per platform model, I started out trying to keep the common code on the master branch, but it proved to be too difficult, So each platform is pretty much independent ... If it would help, I've invited you to be a contributor to the filetree project so that you can do your own management of the squeak support. As you can imagine, filetree is one of the first github projects (using filetree):) and I made the platform per branch decision fairly early on and learned over time that it is not quite the right model to use ... and now it would be difficult to try to switch to a better model -  branch per release with conditional platform code, is my current favorite... I did see your issues, but I've been busy with working on some bugfixes aimed at an imminent release and haven't had the time to look at it in more detail ... things will be a little hectic for me over the next week or so, but hopefully will settle down for a bit, before the next wave hits:) Dale On 8/11/20 8:20 AM, Tim Johnson wrote: > It was working for me as of this weekend also. > > If Timothy feels inspired, I could definitely use the help figuring > out how to update the ConfigurationOfFileTree to use the 2016 commits > from @krono as described in my recent post to the list. > > Without this 2016 fix, the Grease repo doesn't load in Squeak's > Monticello Browser, so efforts to work on the Seaside compatibility > with Squeak (a.k.a., Grease) likely won't be fruitful. > > I view this operation as rather complex, so could definitely use > advice.  I don't know if it's a question of asking Dale to cherry-pick > these commits into the 'master' branch, or update the spec for Squeak, > or both, or neither.  It's also possible (*but unlikely*) that all of > this has been done in /one/ repo, but that the 'Installer > ensureRecentMetacello' is using some /other/ repo somewhere which > contains an older spec or baseline missing these 2016 updates. > > Thanks, > Another Tim > > > On 2020-08-10 12:09, Jakob Reschke wrote: >> Forwarding missing posts to the list with Timothy's approval. >> >> ---------- Forwarded message --------- >> Von: gettimothy >> Date: Sa., 8. Aug. 2020 um 19:48 Uhr >> Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional >> stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due >> to smaltalkhub be bye-bye >> To: Jakob Reschke >> >> >> With Smalltalkhub back up, everthing is installing nicely. >> >> I can now focus on the Seaside compat between Squeak and Pharo. >> >> However, my concerns still hold, it is a bit wierd that a script on >> Gemstones depends on a script on SmalltalkHub. >> >> >> cheers! >> >> tty >> >> >> ---- On Sun, 02 Aug 2020 16:12:54 -0400 Jakob Reschke >> wrote ---- >> >> Probably related thread: >> http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html >> >> >> Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev >> : >>> >>> Hi folks, >>> >>> This probably holds for 5.3 install too. >>> >>> In the preferences wizard, the extras stuff, the Install Metacello >>> ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" >>> >>> iirc, from the pharo discord, SmalltalkHub is going away. >>> >>> You will probably need a different repo. >>> >>> cordially, >>> >>> tty >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale.henrichs at gemtalksystems.com Tue Aug 11 20:30:06 2020 From: dale.henrichs at gemtalksystems.com (Dale Henrichs) Date: Tue, 11 Aug 2020 13:30:06 -0700 Subject: [squeak-dev] Fwd: Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <173dee44f1f.1176e3bd753529.3060846262879091473@zoho.com> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> <173dee44f1f.1176e3bd753529.3060846262879091473@zoho.com> Message-ID: <77c60870-2b74-c95a-8a9c-d2b3780b785a@gemtalksystems.com> Not quite sure what you mean by "Seaside compat" ... Perhaps you are referring to the disk format? Filetree supports multiple disk formats and not storing Monticello meta data is one format. Since 2012 I think there have been something like 10 (slightly) different disk formats and probably 6 of them occurred during the first 6 months of Filetrees life ... the others evolved across the last decade ... so there isn't just one disk format that needs to be supported  ... With that said, I can help provide examples and pointers to code (modulo my current work load:). Dale On 8/11/20 11:59 AM, gettimothy wrote: > If "branch per release with conditional platform code.." is the model > for the Seaside compat, shouldn't we bite the bullet and make Filetree > the same? > > If "branch per release with conditional platform code.." is NOT the > model for the Seaside compat, somebody please inform me. > > thx. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.gade at gmail.com Tue Aug 11 21:24:31 2020 From: eric.gade at gmail.com (Eric Gade) Date: Tue, 11 Aug 2020 17:24:31 -0400 Subject: [squeak-dev] Sound in Linux? Message-ID: Hey all, My Google-fu is failing me on this one. When I try to play sounds in Linux (using the class methods in AbstractSound), nothing happens and I don't hear anything. I assume there are some extra steps I need to take in my system but I cannot find the information online. I'm currently running Pop_os 20.04, which is based on Ubuntu 20.04. Any ideas? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Tue Aug 11 21:26:19 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Tue, 11 Aug 2020 17:26:19 -0400 Subject: [squeak-dev] What is an instSpec? Message-ID: <20200811212619.GA88960@shell.msen.com> One of the interesting aspects of Squeak is how a Class in the image is used to make new object instances in the Squeak VM object memory. I collected some of my recent notes on this topic and put them on the swiki at http://wiki.squeak.org/squeak/6646 Dave From lewis at mail.msen.com Tue Aug 11 21:46:15 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Tue, 11 Aug 2020 17:46:15 -0400 Subject: [squeak-dev] Sound in Linux? In-Reply-To: References: Message-ID: <20200811214615.GA91683@shell.msen.com> On Tue, Aug 11, 2020 at 05:24:31PM -0400, Eric Gade wrote: > Hey all, > > My Google-fu is failing me on this one. When I try to play sounds in Linux > (using the class methods in AbstractSound), nothing happens and I don't > hear anything. I assume there are some extra steps I need to take in my > system but I cannot find the information online. I'm currently running > Pop_os 20.04, which is based on Ubuntu 20.04. > > Any ideas? > > -- > Eric The Unix VM for Squeak supports loadable VM modules for various sound and display drivers. Try "squeak -help" from the command line to see available options. For sound on an Ubuntu-like system, you maiy need to explicitly specify the vm-sound-pulse audio driver. Depending on how your VM is installed, it might look something like this: $ squeak -vm-sound-pulse squeak.image You should be able to do "PluckedSound bachFugue play". Dave From vanessa at codefrau.net Tue Aug 11 22:03:39 2020 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Tue, 11 Aug 2020 15:03:39 -0700 Subject: [squeak-dev] What is an instSpec? In-Reply-To: <20200811212619.GA88960@shell.msen.com> References: <20200811212619.GA88960@shell.msen.com> Message-ID: On Tue, Aug 11, 2020 at 2:26 PM David T. Lewis wrote: > One of the interesting aspects of Squeak is how a Class in the image is > used to make new object instances in the Squeak VM object memory. > > I collected some of my recent notes on this topic and put them on the > swiki at http://wiki.squeak.org/squeak/6646 > > Dave > You are right that some values in the instSpec are unused. However, the instSpec is only used to initialize each object's format bits. Some of the bits are used to store the size of values that are smaller than a full 32 bit word. The size in the object header always refers to full words, so the actual size in e.g. bytes is sizeInWords * 4 - sizeFromFormatBits. So you can't use format code 9 to mean "indexable short (16-bit) field" because codes 8-11 are already used for 8-bit fields of differing sizes between whole words. Format 8 means all 4 bytes of the last word are used, format 9 means only 3 bytes of the last word are actually used, format 10 means 2 bytes are used, and format 11 means only one byte is used. (Or the other way around, I forgot) To add 16 bit fields you need 2 unused format codes, one fore even and one for odd length. For 64 bit fields you would only need a single code. Unless you find another unused bit in the object header we don't have enough bits to represent both 16 and 64 bit arrays. One way may be to not ever allow odd 16 bit arrays I guess? - Vanessa - -------------- next part -------------- An HTML attachment was scrubbed... URL: From digit at sonic.net Wed Aug 12 00:32:18 2020 From: digit at sonic.net (Tim Johnson) Date: Tue, 11 Aug 2020 17:32:18 -0700 Subject: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> Message-ID: <7581E95D-60B8-4A83-9BAA-117277CA4CE7@sonic.net> No worries with timeliness, Dale! Thanks for your help. I understand time pressures and priorities. Knowing that there's no master branch now should help. (I had gotten that idea from the docs[1] so maybe I can update those.) This suggests to me that squeak branch(es) will, eventually, need to evaluate & merge in code from other platform branches. I think our task right now will be to make sure that the FileTree code Squeak currently pulls is the latest it can possibly be. If that brings in @kronos's 2016 commits, at least, we're better off than we were. After that we can look at adopting/merging commits from other platforms if desired. [1] https://github.com/dalehenrich/filetree/blob/master/doc/Contribute.md#branching > On Aug 11, 2020, at 9:08 AM, Dale Henrichs wrote: > > Tim, > > There is no master branch for filetree, the filetree project uses an branch per platform model, I started out trying to keep the common code on the master branch, but it proved to be too difficult, So each platform is pretty much independent ... If it would help, I've invited you to be a contributor to the filetree project so that you can do your own management of the squeak support. > > As you can imagine, filetree is one of the first github projects (using filetree):) and I made the platform per branch decision fairly early on and learned over time that it is not quite the right model to use ... and now it would be difficult to try to switch to a better model - branch per release with conditional platform code, is my current favorite... > > I did see your issues, but I've been busy with working on some bugfixes aimed at an imminent release and haven't had the time to look at it in more detail ... things will be a little hectic for me over the next week or so, but hopefully will settle down for a bit, before the next wave hits:) > > Dale > > On 8/11/20 8:20 AM, Tim Johnson wrote: >> It was working for me as of this weekend also. >> >> If Timothy feels inspired, I could definitely use the help figuring out how to update the ConfigurationOfFileTree to use the 2016 commits from @krono as described in my recent post to the list. >> >> Without this 2016 fix, the Grease repo doesn't load in Squeak's Monticello Browser, so efforts to work on the Seaside compatibility with Squeak (a.k.a., Grease) likely won't be fruitful. >> >> I view this operation as rather complex, so could definitely use advice. I don't know if it's a question of asking Dale to cherry-pick these commits into the 'master' branch, or update the spec for Squeak, or both, or neither. It's also possible (*but unlikely*) that all of this has been done in /one/ repo, but that the 'Installer ensureRecentMetacello' is using some /other/ repo somewhere which contains an older spec or baseline missing these 2016 updates. >> >> Thanks, >> Another Tim >> >> >> On 2020-08-10 12:09, Jakob Reschke wrote: >>> Forwarding missing posts to the list with Timothy's approval. >>> >>> ---------- Forwarded message --------- >>> Von: gettimothy >>> Date: Sa., 8. Aug. 2020 um 19:48 Uhr >>> Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional >>> stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due >>> to smaltalkhub be bye-bye >>> To: Jakob Reschke >>> >>> >>> With Smalltalkhub back up, everthing is installing nicely. >>> >>> I can now focus on the Seaside compat between Squeak and Pharo. >>> >>> However, my concerns still hold, it is a bit wierd that a script on >>> Gemstones depends on a script on SmalltalkHub. >>> >>> >>> cheers! >>> >>> tty >>> >>> >>> ---- On Sun, 02 Aug 2020 16:12:54 -0400 Jakob Reschke >>> wrote ---- >>> >>> Probably related thread: >>> http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html >>> >>> Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev >>> : >>>> >>>> Hi folks, >>>> >>>> This probably holds for 5.3 install too. >>>> >>>> In the preferences wizard, the extras stuff, the Install Metacello ... hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" >>>> >>>> iirc, from the pharo discord, SmalltalkHub is going away. >>>> >>>> You will probably need a different repo. >>>> >>>> cordially, >>>> >>>> tty >>>> >>>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From digit at sonic.net Wed Aug 12 00:34:28 2020 From: digit at sonic.net (Tim Johnson) Date: Tue, 11 Aug 2020 17:34:28 -0700 Subject: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <173dee07d89.c59a898353484.3634821705452097787@zoho.com> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> <173dee07d89.c59a898353484.3634821705452097787@zoho.com> Message-ID: <7E25E31A-2CC8-4A44-9894-202B1445E51E@sonic.net> Hi Timothy, Yes, if we want to work with Grease (the Seaside compatibility layer), we will need to make sure that FileTree is able to load the Grease repo for us to work with it. (Perhaps I can write something up that may help illustrate.) I've got a lead on it now, and will hopefully find some time in the next few days to dig deeper. If not, it may have to wait until next week. Thanks, Tim > On Aug 11, 2020, at 11:55 AM, gettimothy wrote: > > Wow! > > Seaside compat is one of my "dabble in side projects" during downtime, so if this Filetree thing is a pre-req, then I will try. > > Be aware, my time is very limited for the side projects, but I will help as I can. > > cheers, > > > ---- On Tue, 11 Aug 2020 11:20:17 -0400 Tim Johnson wrote ---- > > It was working for me as of this weekend also. > > If Timothy feels inspired, I could definitely use the help figuring out > how to update the ConfigurationOfFileTree to use the 2016 commits from > @krono as described in my recent post to the list. > > Without this 2016 fix, the Grease repo doesn't load in Squeak's > Monticello Browser, so efforts to work on the Seaside compatibility with > Squeak (a.k.a., Grease) likely won't be fruitful. > > I view this operation as rather complex, so could definitely use advice. > I don't know if it's a question of asking Dale to cherry-pick these > commits into the 'master' branch, or update the spec for Squeak, or > both, or neither. It's also possible (*but unlikely*) that all of this > has been done in /one/ repo, but that the 'Installer > ensureRecentMetacello' is using some /other/ repo somewhere which > contains an older spec or baseline missing these 2016 updates. > > Thanks, > Another Tim > > > On 2020-08-10 12:09, Jakob Reschke wrote: > > Forwarding missing posts to the list with Timothy's approval. > > > > ---------- Forwarded message --------- > > Von: gettimothy > > > Date: Sa., 8. Aug. 2020 um 19:48 Uhr > > Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional > > stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due > > to smaltalkhub be bye-bye > > To: Jakob Reschke > > > > > > > With Smalltalkhub back up, everthing is installing nicely. > > > > I can now focus on the Seaside compat between Squeak and Pharo. > > > > However, my concerns still hold, it is a bit wierd that a script on > > Gemstones depends on a script on SmalltalkHub. > > > > > > cheers! > > > > tty > > > > > > ---- On Sun, 02 Aug 2020 16:12:54 -0400 Jakob Reschke > > > wrote ---- > > > > Probably related thread: > > http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html > > > > Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev > > >: > >> > >> Hi folks, > >> > >> This probably holds for 5.3 install too. > >> > >> In the preferences wizard, the extras stuff, the Install Metacello ... > >> hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main " > >> > >> iirc, from the pharo discord, SmalltalkHub is going away. > >> > >> You will probably need a different repo. > >> > >> cordially, > >> > >> tty > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at stlutz.net Wed Aug 12 10:11:49 2020 From: dev at stlutz.net (Stephan Lutz) Date: Wed, 12 Aug 2020 12:11:49 +0200 Subject: [squeak-dev] Rounding in MatrixTransform2x3 In-Reply-To: References: <338f01a9-a5a3-eb4a-2369-f1f06723f9c8@stlutz.net> Message-ID: <9b3b3435-b8e5-e2c7-4f8a-7cbdebbafc2b@stlutz.net> Ah, yes. I hadn't even thought about that. Probably because I've only ever used Squeak on 64bits with immediate floats ^^. I followed your suggestion and implemented a Matrix2x3 in pure Smalltalk. It's actually really fast and surprisingly even beats the existing implementation in quite a few cases. :D Most notably, the plugin-supported point transformation (/localPointToGlobal:/) is actually slower on my machine. Only the transformation of multiple points at a time, as done in /localBoundsToGlobal:/ is significantly (~3x) faster using the plugin. Below are some of the measurements I have taken in a 64bit trunk image using squeak.cog.spur_linux64x64: "--------------------------------" " localPointToGlobal: " "--------------------------------" [mat2x3Old localPointToGlobal: -10 @ 10] bench. " '11,700,000 per second. 85.6 nanoseconds per run. 1.43971 % GC time.'" [mat2x3Old transformPoint: -10 @ 10] bench. " '2,330,000 per second. 429 nanoseconds per run. 0.37985 % GC time.'" [mat2x3New localPointToGlobal: -10 @ 10] bench. " '12,500,000 per second. 80.3 nanoseconds per run. 1.89962 % GC time.'" [morphic localPointToGlobal: -10 @ 10] bench. " '2,710,000 per second. 370 nanoseconds per run. 1.16 % GC time.'" "--------------------------------" " localBoundsToGlobal: " "--------------------------------" [mat2x3Old localBoundsToGlobal: rect] bench. " '6,770,000 per second. 148 nanoseconds per run. 1.67966 % GC time.'" [mat2x3New localBoundsToGlobal: rect] bench. " '2,090,000 per second. 480 nanoseconds per run. 1.55969 % GC time.'" [morphic localBoundsToGlobal: rect] bench. " '505,000 per second. 1.98 microseconds per run. 1.95922 % GC time.'" "--------------------------------" " localBoundsToGlobal: (pure translation) " "--------------------------------" [mat2x3OldTranslation localBoundsToGlobal: rect] bench. " '6,780,000 per second. 147 nanoseconds per run. 1.7 % GC time.'" [mat2x3NewTranslation localBoundsToGlobal: rect] bench. " '5,860,000 per second. 171 nanoseconds per run. 1.48 % GC time.'" [morphicTranslation localBoundsToGlobal: rect] bench. " '1,580,000 per second. 631 nanoseconds per run. 4.12 % GC time.'" "--------------------------------" "composedWithLocal:" "--------------------------------" [mat2x3Old composedWithLocal: mat2x3OldRotation] bench. " '9,670,000 per second. 103 nanoseconds per run. 1.19976 % GC time.'" [mat2x3New composedWithLocal: mat2x3NewRotation] bench. " '6,920,000 per second. 144 nanoseconds per run. 1.4997 % GC time.'" [morphic composedWithLocal: morphicRotation] bench. " '11,100,000 per second. 89.8 nanoseconds per run. 1.09978 % GC time.'" "--------------------------------" " instance creation " "--------------------------------" [MatrixTransform2x3 withOffset: offset] bench. " '3,320,000 per second. 301 nanoseconds per run. 1.91962 % GC time.'" [Matrix2x3 withOffset: offset] bench. " '24,800,000 per second. 40.3 nanoseconds per run. 10.63787 % GC time.'" [MorphicTransform offset: offset] bench. " '43,600,000 per second. 22.9 nanoseconds per run. 7.63847 % GC time.'" There are quite a few more benchmarks in the attached file. I have also attached a change set of the implementation I used, so you can try it out for yourselves if you'd like :) Cheers Stephan On 28.07.20 19:33, Vanessa Freudenberg wrote: > On Tue, Jul 28, 2020 at 4:34 AM Stephan Lutz > wrote: > > While transforming points using MatrixTransform2x3 we noticed some > strange rounding behavior: > > "with plugin" > (MatrixTransform2x3 withOffset: 5 @ 10) localPointToGlobal: > 0 at 0. "5 at 10" > (MatrixTransform2x3 withOffset: -5 @ -10) localPointToGlobal: > 0 at 0. "-4@ -9" > > "without plugin" > ((MatrixTransform2x3 withOffset: 5 @ 10) transformPoint: 0 at 0) > rounded. "5 at 10" > ((MatrixTransform2x3 withOffset: -5 @ -10) transformPoint: > 0 at 0) rounded. "-5@ -10" > > It appears the code used to round in the plugin simply adds 0.5 > and truncates the result, which does not work correctly for > negative numbers. > This code can be found in Matrix2x3Plugin >> > #roundAndStoreResultPoint: and Matrix2x3Plugin >> > #roundAndStoreResultRect:x0:y0:x1:y1: . > > ---- > > On a kind of related note: Is there even a reason to round the > resulting floats? > > While the class comment of MatrixTransform2x3 notes that this > behavior is intentional, glancing quickly over its uses we could > not find anything taking advantage or benefiting from it. It's > also not a limitation of the DisplayTransform interface, since > MorphicTransform does produce floating point values. Wouldn't it > be much more versatile and easier to leave rounding to users if > they actually need it? > > No. Having a float result means that the primitive would need to > allocate two Float objects. Any allocation can fail due to memory > exhaustion. So the primitive would have to be made to retry the > allocation after running a garbage collection. > > Secondly, its results are primarily used to set up a WarpBlt IIRC, for > drawing rotated user objects in Etoys. WarpBlt fails if the coords are > not integers. The failure code rounds the numbers and retries. Doing > the rounding in the matrix primitives ensured a fast path to rendering > - that's why it was done that way. > > So, there are very good reasons why the plugin returns integers. And > there are Squeak VMs where this still is a very reasonable behavior. > It also would be a good idea to document the reasoning in the class > comment of MatrixTransform2x3. > > That being said, there is virtually no reason to use it when running > on Cog, much less Sista, especially on 64 bits where we have immediate > floats. An interesting thing would be to compare a pure Smalltalk > implementation to the performance of the plugin. If you need floating > point transform results, just write it in Smalltalk, would be my > suggestion. > > - Vanessa - > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- rect := 100 at 200 extent: 300 at 400. offset := 500 at 600. angle := 42. mat2x3Old := (MatrixTransform2x3 withRotation: 70) offset: offset. mat2x3New := (Matrix2x3 withRotation: 70) setOffset: offset. morphic := (MorphicTransform offset: offset negated angle: 70 scale: 1). mat2x3OldTranslation := MatrixTransform2x3 withOffset: offset. mat2x3NewTranslation := Matrix2x3 withOffset: offset. morphicTranslation := MorphicTransform offset: offset negated. mat2x3OldRotation := MatrixTransform2x3 withRotation: angle. mat2x3NewRotation := Matrix2x3 withRotation: angle. morphicRotation := MorphicTransform offset: 0 at 0 angle: angle negated degreesToRadians scale: 1.0. mat2x3OldIdentity := MatrixTransform2x3 identity. mat2x3NewIdentity := Matrix2x3 identity. morphicIdentity := MorphicTransform identity. "--------------------------------" " localPointToGlobal: " "--------------------------------" [mat2x3Old localPointToGlobal: -10 @ 10] bench. " '11,700,000 per second. 85.6 nanoseconds per run. 1.43971 % GC time.'" [mat2x3Old transformPoint: -10 @ 10] bench. " '2,330,000 per second. 429 nanoseconds per run. 0.37985 % GC time.'" [mat2x3New localPointToGlobal: -10 @ 10] bench. " '12,500,000 per second. 80.3 nanoseconds per run. 1.89962 % GC time.'" [morphic localPointToGlobal: -10 @ 10] bench. " '2,710,000 per second. 370 nanoseconds per run. 1.16 % GC time.'" "--------------------------------" " localBoundsToGlobal: " "--------------------------------" [mat2x3Old localBoundsToGlobal: rect] bench. " '6,770,000 per second. 148 nanoseconds per run. 1.67966 % GC time.'" [mat2x3New localBoundsToGlobal: rect] bench. " '2,090,000 per second. 480 nanoseconds per run. 1.55969 % GC time.'" [morphic localBoundsToGlobal: rect] bench. " '505,000 per second. 1.98 microseconds per run. 1.95922 % GC time.'" "--------------------------------" " localBoundsToGlobal: (pure translation) " "--------------------------------" [mat2x3OldTranslation localBoundsToGlobal: rect] bench. " '6,780,000 per second. 147 nanoseconds per run. 1.7 % GC time.'" [mat2x3NewTranslation localBoundsToGlobal: rect] bench. " '5,860,000 per second. 171 nanoseconds per run. 1.48 % GC time.'" [morphicTranslation localBoundsToGlobal: rect] bench. " '1,580,000 per second. 631 nanoseconds per run. 4.12 % GC time.'" "--------------------------------" " globalPointToLocal: " "--------------------------------" [mat2x3Old globalPointToLocal: -10 @ 10] bench. " '11,300,000 per second. 88.3 nanoseconds per run. 1.79964 % GC time.'" [mat2x3Old invertPoint: -10 @ 10] bench. " '2,470,000 per second. 405 nanoseconds per run. 0.45991 % GC time.'" [mat2x3New globalPointToLocal: -10 @ 10] bench. " '8,950,000 per second. 112 nanoseconds per run. 1.5197 % GC time.'" [morphic globalPointToLocal: -10 @ 10] bench. " '2,720,000 per second. 368 nanoseconds per run. 1.19976 % GC time.'" "--------------------------------" "globalBoundsToLocal:" "--------------------------------" [mat2x3Old globalBoundsToLocal: rect] bench. " '6,210,000 per second. 161 nanoseconds per run. 1.69966 % GC time.'" [mat2x3New globalBoundsToLocal: rect] bench. " '1,720,000 per second. 581 nanoseconds per run. 1.41972 % GC time.'" [morphic globalBoundsToLocal: rect] bench. " '465,000 per second. 2.15 microseconds per run. 2.08 % GC time.'" "--------------------------------" "globalBoundsToLocal: (pure translation)" "--------------------------------" [mat2x3OldTranslation globalBoundsToLocal: rect] bench. " '6,280,000 per second. 159 nanoseconds per run. 1.73965 % GC time.'" [mat2x3NewTranslation globalBoundsToLocal: rect] bench. " '4,060,000 per second. 246 nanoseconds per run. 1.13977 % GC time.'" [morphicTranslation globalBoundsToLocal: rect] bench. " '1,500,000 per second. 668 nanoseconds per run. 4.36 % GC time.'" "--------------------------------" "composedWithLocal:" "--------------------------------" [mat2x3Old composedWithLocal: mat2x3OldRotation] bench. " '9,670,000 per second. 103 nanoseconds per run. 1.19976 % GC time.'" [mat2x3New composedWithLocal: mat2x3NewRotation] bench. " '6,920,000 per second. 144 nanoseconds per run. 1.4997 % GC time.'" [morphic composedWithLocal: morphicRotation] bench. " '11,100,000 per second. 89.8 nanoseconds per run. 1.09978 % GC time.'" "--------------------------------" " inverseTransformation " "--------------------------------" [mat2x3Old inverseTransformation] bench. " '584,000 per second. 1.71 microseconds per run. 0.55989 % GC time.'" [mat2x3New inverseTransformation] bench. " '2,450,000 per second. 408 nanoseconds per run. 2.27954 % GC time.'" [morphic inverseTransformation] bench. " '1,230,000 per second. 813 nanoseconds per run. 1.19976 % GC time.'" "--------------------------------" " = " "--------------------------------" mx := mat2x3Old copy. [mat2x3Old = mx] bench. " '16,900,000 per second. 59.1 nanoseconds per run. 0 % GC time.'" mx := mat2x3New copy. [mat2x3New = mx] bench. " '17,500,000 per second. 57.1 nanoseconds per run. 0 % GC time.'" mx := morphic copy. [morphic = mx] bench. "identity check" " '97,600,000 per second. 10.3 nanoseconds per run. 0 % GC time.'" "--------------------------------" " instance creation " "--------------------------------" [MatrixTransform2x3 withOffset: offset] bench. " '3,320,000 per second. 301 nanoseconds per run. 1.91962 % GC time.'" [Matrix2x3 withOffset: offset] bench. " '24,800,000 per second. 40.3 nanoseconds per run. 10.63787 % GC time.'" [MorphicTransform offset: offset] bench. " '43,600,000 per second. 22.9 nanoseconds per run. 7.63847 % GC time.'" "--------------------------------" " isPureTranslation " "--------------------------------" [mat2x3Old isPureTranslation] bench. " '22,000,000 per second. 45.4 nanoseconds per run. 0 % GC time.'" [mat2x3New isPureTranslation] bench. " '77,000,000 per second. 13 nanoseconds per run. 0 % GC time.'" [morphic isPureTranslation] bench. " '76,600,000 per second. 13.1 nanoseconds per run. 0 % GC time.'" "--------------------------------" " isPureTranslation (pure translation)" "--------------------------------" [mat2x3OldTranslation isPureTranslation] bench. " '21,000,000 per second. 47.7 nanoseconds per run. 0 % GC time.'" [mat2x3NewTranslation isPureTranslation] bench. " '38,700,000 per second. 25.8 nanoseconds per run. 0 % GC time.'" [morphicTranslation isPureTranslation] bench. " '60,400,000 per second. 16.6 nanoseconds per run. 0 % GC time.'" "--------------------------------" " isIdentity " "--------------------------------" [mat2x3Old isIdentity] bench. " '23,700,000 per second. 42.1 nanoseconds per run. 0 % GC time.'" [mat2x3New isIdentity] bench. " '76,500,000 per second. 13.1 nanoseconds per run. 0 % GC time.'" [morphic isIdentity] bench. " '58,400,000 per second. 17.1 nanoseconds per run. 0 % GC time.'" "--------------------------------" " isIdentity (identity) " "--------------------------------" [mat2x3OldIdentity isIdentity] bench. " '22,100,000 per second. 45.1 nanoseconds per run. 0 % GC time.'" [mat2x3NewIdentity isIdentity] bench. " '28,000,000 per second. 35.8 nanoseconds per run. 0 % GC time.'" [morphicIdentity isIdentity] bench. " '19,500,000 per second. 51.2 nanoseconds per run. 0.89982 % GC time.'" "--------------------------------" "--------------------------------" -------------- next part -------------- A non-text attachment was scrubbed... Name: Matrix2x3.1.cs Type: text/x-csharp Size: 8534 bytes Desc: not available URL: From gettimothy at zoho.com Wed Aug 12 12:15:52 2020 From: gettimothy at zoho.com (gettimothy) Date: Wed, 12 Aug 2020 08:15:52 -0400 Subject: [squeak-dev] Fwd: Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <77c60870-2b74-c95a-8a9c-d2b3780b785a@gemtalksystems.com> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> <173dee44f1f.1176e3bd753529.3060846262879091473@zoho.com> <77c60870-2b74-c95a-8a9c-d2b3780b785a@gemtalksystems.com> Message-ID: <173e2991dda.e6bca692300245.4639967821293980386@zoho.com> Hi The Seasude compatability layer will address portability between pharo to squeak; my interest is that I like Seaside on Squeak but thevPharo team do not want to, and should not want to , imho, maintain Squeak compatability. >From this thread, I read that task depends on Filetree,, which I have no understanding of, but, I will delve into that to support flawless Seaside support on Squeak. Hth. ---- On Tue, 11 Aug 2020 16:30:06 -0400 dale.henrichs at gemtalksystems.com wrote ---- Not quite sure what you mean by "Seaside compat" ... Perhaps you are referring to the disk format? Filetree supports multiple disk formats and not storing Monticello meta data is one format. Since 2012 I think there have been something like 10 (slightly) different disk formats and probably 6 of them occurred during the first 6 months of Filetrees life ... the others evolved across the last decade ... so there isn't just one disk format that needs to be supported  ... With that said, I can help provide examples and pointers to code (modulo my current work load:). Dale On 8/11/20 11:59 AM, gettimothy wrote: If "branch per release with conditional platform code.." is the model for the Seaside compat, shouldn't we bite the bullet and make Filetree the same? If "branch per release with conditional platform code.." is NOT the model for the Seaside compat, somebody please inform me.  thx. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gettimothy at zoho.com Wed Aug 12 12:19:04 2020 From: gettimothy at zoho.com (gettimothy) Date: Wed, 12 Aug 2020 08:19:04 -0400 Subject: [squeak-dev] Squeak6.0 alpha, install, add additional stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due to smaltalkhub be bye-bye In-Reply-To: <7E25E31A-2CC8-4A44-9894-202B1445E51E@sonic.net> References: <173ae8cce7a.b3bc092f8232.3820629186117434248@zoho.com> <173cf30552f.11ee6504615974.3637334827247671126@zoho.com> <173dee07d89.c59a898353484.3634821705452097787@zoho.com> <7E25E31A-2CC8-4A44-9894-202B1445E51E@sonic.net> Message-ID: <173e29c0d67.11580bff7298919.359509880184715765@zoho.com> Hi, I will poke around this stuff this weekend. I am on a huge XTreams parseing project that eats most of my coding time, so I apreciate others doing the thinking whilevI contribute grunt work Cheers ---- On Tue, 11 Aug 2020 20:34:28 -0400 digit at sonic.net wrote ---- Hi Timothy, Yes, if we want to work with Grease (the Seaside compatibility layer), we will need to make sure that FileTree is able to load the Grease repo for us to work with it.  (Perhaps I can write something up that may help illustrate.) I've got a lead on it now, and will hopefully find some time in the next few days to dig deeper.  If not, it may have to wait until next week. Thanks, Tim On Aug 11, 2020, at 11:55 AM, gettimothy wrote: Wow! Seaside compat is one of my "dabble in side projects" during downtime, so if this Filetree thing is a pre-req, then I will try. Be aware, my time is very limited for the side projects, but I will help as I can. cheers, ---- On Tue, 11 Aug 2020 11:20:17 -0400 Tim Johnson wrote ---- It was working for me as of this weekend also. If Timothy feels inspired, I could definitely use the help figuring out how to update the ConfigurationOfFileTree to use the 2016 commits from @krono as described in my recent post to the list. Without this 2016 fix, the Grease repo doesn't load in Squeak's Monticello Browser, so efforts to work on the Seaside compatibility with Squeak (a.k.a., Grease) likely won't be fruitful. I view this operation as rather complex, so could definitely use advice. I don't know if it's a question of asking Dale to cherry-pick these commits into the 'master' branch, or update the spec for Squeak, or both, or neither. It's also possible (*but unlikely*) that all of this has been done in /one/ repo, but that the 'Installer ensureRecentMetacello' is using some /other/ repo somewhere which contains an older spec or baseline missing these 2016 updates. Thanks, Another Tim On 2020-08-10 12:09, Jakob Reschke wrote: > Forwarding missing posts to the list with Timothy's approval. > > ---------- Forwarded message --------- > Von: gettimothy > Date: Sa., 8. Aug. 2020 um 19:48 Uhr > Subject: Re: [squeak-dev] Squeak6.0 alpha, install, add additional > stuff--Metacello, Git, OSProcess, Grift, Malfeascance, etc fails due > to smaltalkhub be bye-bye > To: Jakob Reschke > > > With Smalltalkhub back up, everthing is installing nicely. > > I can now focus on the Seaside compat between Squeak and Pharo. > > However, my concerns still hold, it is a bit wierd that a script on > Gemstones depends on a script on SmalltalkHub. > > > cheers! > > tty > > > ---- On Sun, 02 Aug 2020 16:12:54 -0400 Jakob Reschke > wrote ---- > > Probably related thread: > http://forum.world.st/Metacello-bootstrap-fails-due-to-download-timeouts-td5119637.html > > Am So., 2. Aug. 2020 um 11:42 Uhr schrieb gettimothy via Squeak-dev > : >> >> Hi folks, >> >> This probably holds for 5.3 install too. >> >> In the preferences wizard, the extras stuff, the Install Metacello ... >> hangs at "Updating http://smalltalkhub.com/foo/bar/metacello/main" >> >> iirc, from the pharo discord, SmalltalkHub is going away. >> >> You will probably need a different repo. >> >> cordially, >> >> tty >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Wed Aug 12 18:16:23 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Wed, 12 Aug 2020 14:16:23 -0400 Subject: [squeak-dev] What is an instSpec? In-Reply-To: References: <20200811212619.GA88960@shell.msen.com> Message-ID: <20200812181623.GA84874@shell.msen.com> On Tue, Aug 11, 2020 at 03:03:39PM -0700, Vanessa Freudenberg wrote: > On Tue, Aug 11, 2020 at 2:26 PM David T. Lewis wrote: > > > One of the interesting aspects of Squeak is how a Class in the image is > > used to make new object instances in the Squeak VM object memory. > > > > I collected some of my recent notes on this topic and put them on the > > swiki at http://wiki.squeak.org/squeak/6646 > > > > Dave > > > > You are right that some values in the instSpec are unused. However, the > instSpec is only used to initialize each object's format bits. Some of the > bits are used to store the size of values that are smaller than a full 32 > bit word. The size in the object header always refers to full words, so the > actual size in e.g. bytes is sizeInWords * 4 - sizeFromFormatBits. > > So you can't use format code 9 to mean "indexable short (16-bit) field" > because codes 8-11 are already used for 8-bit fields of differing sizes > between whole words. Format 8 means all 4 bytes of the last word are used, > format 9 means only 3 bytes of the last word are actually used, format 10 > means 2 bytes are used, and format 11 means only one byte is used. (Or the > other way around, I forgot) > > To add 16 bit fields you need 2 unused format codes, one fore even and one > for odd length. > > For 64 bit fields you would only need a single code. > > Unless you find another unused bit in the object header we don't have > enough bits to represent both 16 and 64 bit arrays. One way may be to not > ever allow odd 16 bit arrays I guess? > Vanessa, Thank you for the careful review and for the correction. I added a short note on the swiki page, and I'll clean it up properly soon-ish. Much appreciated, Dave From trygver at ifi.uio.no Thu Aug 13 07:34:16 2020 From: trygver at ifi.uio.no (Trygve Reenskaug) Date: Thu, 13 Aug 2020 09:34:16 +0200 Subject: [squeak-dev] A Sad Day Message-ID: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Dear All, Imagine that you bought an iPhone 20 years ago. Over the years, you have filled it with pictures, contacts, and other personal data. You now want to upgrade to iPhone SE and find that all your personal data are lost because there is no way to transfer your data. Very sad. The same has happened to me with Squeak. The Squeak programs I have written over the past 20 years are effectively lost because I can’t port them to a current version of Squeak. Very sad. The essence of object orientation is that objects collaborate to achieve a goal. I retired 20 years ago and made it my task to create DCI (Data-Context-Interaction), a programming paradigm that merges the concepts of class and collaboration. BabyIDE is a non-intrusive Squeak program that includes a model of DCI as well as tools for programming within the paradigm. BabyIDE is a kind of Dynabook, a personal computer for experts in all domains. Its target group could be department managers in business and industry; they are experts in running their department in collaboration with other managers. Another target group could be farmers; they are experts in taking care of their animals. A third target group could be homeowners; they build expertise in controlling their smart home. Squeak is more than a programming language; it is a live universe of collaborating objects. The shared objects on the web is also a universe of collaborating objects that Kevin Kelly called a /single, global machine/. BabyIDE extends the Squeak image into this global machine, making all the combined objects available for personal programming as illustrated below: BabyIDE is now running in Squeak 3.10.2, together with a new Squeak Reverse Engineering tool. I want to port my programs to Squeak 3.5 to benefit from its improved internet communication facilities. This port has been pestering me since April, but the overwhelming complexity of 3.5 has forced me to accept defeat. I can’t avoid speculating about the nature of Squeak’s current target group. It used to be “children of all ages.” Today, it neither includes children nor old Smalltalk hands like me (I wrote my first Smalltalk program in 1978). Stephen Pope, another veteran who also bemoans what is happening to Squeak, wrote in a blog: /“//The most popular systems (Squeak and Pharo) both suffer from unbelievable image bloat, with many thousands of classes, hundreds of root classes, class hierarchies with many instance variables in the high-level (abstract) classes, and too many packages with cute but meaningless (to a new-comer) names.”/ https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ I couldn’t agree more. A few examples: 1.Class Object defines 485 methods. This means that every Squeak object understands at least 485 messages. Most of them are irrelevant to the problem at hand, but all of them can be part of unexpected behavior. 2.The state of every Morph object is held in its regular instance variables PLUS any number of undeclared and undocumented variables in its /extension/, a Dictionary that may include another dictionary inside it. The Morph class comment: /“MorphExtension Allows extra properties to be stored without adding a storage burden to all morphs.”/ I’m more concerned about the burden put upon the code reader. 3.For me, the final straw was the new filtering phase added to Squeak’s already complex event handling mechanism. Squeak 3.5 has 208 new methods with ‘filter’ in their name, but there is no indication as to what they are for and when to use them. The abstract concepts of event filtering are documented, but there is no documentation on their reification into concrete code. The complexity of a basically simple mechanism has reached a new high far beyond the capabilities of my brain. 4.Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 methods in 5.3. 5.Class /MyMorph>> processEvent: anEvent using: anIgnoredDispatcher/ is a regular event handler in 3.10.2. In 5.3, it is a filter, and its execution never stops. After 60 years in programming, 42 of them in Smalltalk, and the last 20 in Squeak, I have reached the end of my patience and reluctantly have to quit Squeak programming. It is truly a sad day. Have fun and Goodbye, --Trygve -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver at ifi.uio.no Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 468 58 625 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hikoacdgfinifkep.png Type: image/png Size: 85882 bytes Desc: not available URL: From marcel.taeumel at hpi.de Thu Aug 13 07:59:34 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 13 Aug 2020 09:59:34 +0200 Subject: [squeak-dev] A Sad Day In-Reply-To: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: Hi Trygve. > Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 methods in 5.3. Finally, we managed to improve modularity of Squeak's event handling by assembling -- once scattered -- methods and logic in a place where it can be found and understood. Of course, the number of methods in a class can go up in the process. What you describe as "additional bloat" is clearly a revelation of already existing complexity. Since the plain number of methods is rather unhelpful to assess code readability, I wonder whether there are better names we can use to guide programmers when exploring MorphicEventDispatcher, its protocols, and methods. > Class MyMorph>> processEvent: anEvent using: anIgnoredDispatcher is a regular event handler in 3.10.2. In 5.3, it is a filter, and its execution never stops. That's just not true. The dispatcher is still dispatching as it was in Squeak 3.10.2. Event filters were added as a mechanism to tackle the existing mis-use of event listeners. The filter mechanism uses patterns that are already existing in the Squeak system. Yes, there is still room for improvement regarding its modularity. *** We need better ways to assess the image quality. Phrases such as "unbelievable image bloat", "many thousands of classes", etc. are not helpful at all. Such a perspective ignores incidental vs. accidental complexity. It also ignores the role of tools in such a live and exploratory programming system. We need better ways to look beyond the source code. Of course, we strive for a clean, compact, understandable system. However, that goal must not only focus on lines of code, number of methods/classes/packages. Programmers do not just read code to gather understanding. They execute code, play around with objects ---> use tools. Those tools show us the names and relationships of all kinds of software artifacts. Those tools enable very concise, task-specific views on rather complex systems. Those tools can help find redundancy, clarify meaning. Don't get me wrong. I am always in favor of removing a class or concept if that is not necessary. I do think twice before adding a new class or extending the inheritance tree. However, just counting the number of code artifacts is not a helpful metric to move forward. It can only be a first step in a more throrough exploration process. Don't give up. Happy Squeaking! :-) Best, Marcel Am 13.08.2020 09:34:39 schrieb Trygve Reenskaug : Dear All, Imagine that you bought an iPhone 20 years ago. Over the years, you have filled it with pictures, contacts, and other personal data. You now want to upgrade to iPhone SE and find that all your personal data are lost because there is no way to transfer your data. Very sad. The same has happened to me with Squeak. The Squeak programs I have written over the past 20 years are effectively lost because I can’t port them to a current version of Squeak. Very sad. The essence of object orientation is that objects collaborate to achieve a goal. I retired 20 years ago and made it my task to create DCI (Data-Context-Interaction), a programming paradigm that merges the concepts of class and collaboration. BabyIDE is a non-intrusive Squeak program that includes a model of DCI as well as tools for programming within the paradigm. BabyIDE is a kind of Dynabook, a personal computer for experts in all domains. Its target group could be department managers in business and industry; they are experts in running their department in collaboration with other managers. Another target group could be farmers; they are experts in taking care of their animals. A third target group could be homeowners; they build expertise in controlling their smart home. Squeak is more than a programming language; it is a live universe of collaborating objects. The shared objects on the web is also a universe of collaborating objects that Kevin Kelly called a single, global machine. BabyIDE extends the Squeak image into this global machine, making all the combined objects available for personal programming as illustrated below: BabyIDE is now running in Squeak 3.10.2, together with a new Squeak Reverse Engineering tool. I want to port my programs to Squeak 3.5 to benefit from its improved internet communication facilities. This port has been pestering me since April, but the overwhelming complexity of 3.5 has forced me to accept defeat. I can’t avoid speculating about the nature of Squeak’s current target group. It used to be “children of all ages.” Today, it neither includes children nor old Smalltalk hands like me (I wrote my first Smalltalk program in 1978). Stephen Pope, another veteran who also bemoans what is happening to Squeak, wrote in a blog: “The most popular systems (Squeak and Pharo) both suffer from unbelievable image bloat, with many thousands of classes, hundreds of root classes, class hierarchies with many instance variables in the high-level (abstract) classes, and too many packages with cute but meaningless (to a new-comer) names.” https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ [https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/] I couldn’t agree more. A few examples: 1.   Class Object defines 485 methods. This means that every Squeak object understands at least 485 messages. Most of them are irrelevant to the problem at hand, but all of them can be part of unexpected behavior.  2.   The state of every Morph object is held in its regular instance variables PLUS any number of undeclared and undocumented variables in its extension, a Dictionary that may include another dictionary inside it. The Morph class comment: “MorphExtension Allows extra properties to be stored without adding a storage burden to all morphs.” I’m more concerned about the burden put upon the code reader. 3.   For me, the final straw was the new filtering phase added to Squeak’s already complex event handling mechanism. Squeak 3.5 has 208 new methods with ‘filter’ in their name, but there is no indication as to what they are for and when to use them. The abstract concepts of event filtering are documented, but there is no documentation on their reification into concrete code. The complexity of a basically simple mechanism has reached a new high far beyond the capabilities of my brain. 4.   Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 methods in 5.3. 5.   Class MyMorph>> processEvent: anEvent using: anIgnoredDispatcher is a regular event handler in 3.10.2. In 5.3, it is a filter, and its execution never stops. After 60 years in programming, 42 of them in Smalltalk, and the last 20 in Squeak, I have reached the end of my patience and reluctantly have to quit Squeak programming. It is truly a sad day. Have fun and Goodbye, --Trygve -- The essence of object orientation is that objects collaborate  to achieve a goal. Trygve Reenskaug      mailto: trygver at ifi.uio.no [mailto:%20trygver at ifi.uio.no] Morgedalsvn. 5A       http://folk.uio.no/trygver/ [http://folk.uio.no/trygver/] N-0378 Oslo             http://fullOO.info [http://fullOO.info] Norway                     Tel: (+47) 468 58 625 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hikoacdgfinifkep.png Type: image/png Size: 85882 bytes Desc: not available URL: From LEnglish5 at cox.net Thu Aug 13 10:11:38 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Thu, 13 Aug 2020 03:11:38 -0700 Subject: [squeak-dev] FFI and mpfr calls in squeak Message-ID: So I tested a simple mandelbrot set rendering algorithm using the ArbitraryPrecisionFloat package and it works just fine, but terribly slowly. So I had the idea of using mpfr via FFI and find that I can’t even begin. I’m getting the dreaded External module not found error and just can’t get rid of it. I thought I was taking the easy route and simply copying the mpfr library into the Squeak all-in-one Resources directory but no matter what I try, that error pops up. initPrecision: aDefaultPrecision “initialize default precision" ^self externalCallFailed This is roughly the “hello world” of using mpfr, I thought, but can’t even do that. Now, waiting in the wings is a bigger problem, I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? Compile both libraries into a single target? (yikes!). That might be an issue later on, but the impression I’m getting is that squeak simply can’t find libmpfr.6.dylib, so errors that result from calling a second library from the first haven’t even popped up yet. Squeak5.3-19435-64bit, Mac OS X 10.15.6 Thanks Lawson From edgardec2005 at gmail.com Thu Aug 13 10:19:49 2020 From: edgardec2005 at gmail.com (Edgar J. De Cleene) Date: Thu, 13 Aug 2020 07:19:49 -0300 Subject: [squeak-dev] A Sad Day In-Reply-To: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: >>> > > > On 8/13/20, 4:34 AM, "Trygve Reenskaug" wrote: > >> >> Dear All, >> Imagine that you bought an iPhone 20 years ago. Over the years, you have >> filled it with pictures, contacts, and other personal data. You now want to >> upgrade to iPhone SE and find that all your personal data are lost because >> there is no way to transfer your data. Very sad. >> >> The same has happened to me with Squeak. The Squeak programs I have written >> over the past 20 years are effectively lost because I can¹t port them to a >> current version of Squeak. Very sad. >> >> The essence of object orientation is that objects collaborate to achieve a >> goal. I retired 20 years ago and made it my task to create DCI >> (Data-Context-Interaction), a programming paradigm that merges the concepts >> of class and collaboration. BabyIDE is a non-intrusive Squeak program that >> includes a model of DCI as well as tools for programming within the paradigm. >> BabyIDE is a kind of Dynabook, a personal computer for experts in all >> domains. Its target group could be department managers in business and >> industry; they are experts in running their department in collaboration with >> other managers. Another target group could be farmers; they are experts in >> taking care of their animals. A third target group could be homeowners; they >> build expertise in controlling their smart home. >> >> Squeak is more than a programming language; it is a live universe of >> collaborating objects. The shared objects on the web is also a universe of >> collaborating objects that Kevin Kelly called a single, global machine. >> BabyIDE extends the Squeak image into this global machine, making all the >> combined objects available for personal programming as illustrated below: >> >> >> >> >> >> BabyIDE is now running in Squeak 3.10.2, together with a new Squeak Reverse >> Engineering tool. I want to port my programs to Squeak 3.5 to benefit from >> its improved internet communication facilities. This port has been pestering >> me since April, but the overwhelming complexity of 3.5 has forced me to >> accept defeat. I can¹t avoid speculating about the nature of Squeak¹s current >> target group. It used to be ³children of all ages.² Today, it neither >> includes children nor old Smalltalk hands like me (I wrote my first Smalltalk >> program in 1978). Stephen Pope, another veteran who also bemoans what is >> happening to Squeak, wrote in a blog: >> >> >>> ³The most popular systems (Squeak and Pharo) both suffer from unbelievable >>> image bloat, with many thousands of classes, hundreds of root classes, class >>> hierarchies with many instance variables in the high-level (abstract) >>> classes, and too many packages with cute but meaningless (to a new-comer) >>> names.² >>> https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ >>> >>> >>> I couldn¹t agree more. A few examples: >>> >>> >>>> 1.   Class Object defines 485 methods. This means that every Squeak object >>>> understands at least 485 messages. Most of them are irrelevant to the >>>> problem at hand, but all of them can be part of unexpected behavior.  >>>> >>>> 2.   The state of every Morph object is held in its regular instance >>>> variables PLUS any number of undeclared and undocumented variables in its >>>> extension, a Dictionary that may include another dictionary inside it. The >>>> Morph class comment: ³MorphExtension Allows extra properties to be stored >>>> without adding a storage burden to all morphs.² I¹m more concerned about >>>> the burden put upon the code reader. >>>> >>>> 3.   For me, the final straw was the new filtering phase added to Squeak¹s >>>> already complex event handling mechanism. Squeak 3.5 has 208 new methods >>>> with Œfilter¹ in their name, but there is no indication as to what they are >>>> for and when to use them. The abstract concepts of event filtering are >>>> documented, but there is no documentation on their reification into >>>> concrete code. The complexity of a basically simple mechanism has reached a >>>> new high far beyond the capabilities of my brain. >>>> >>>> 4.   Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 methods >>>> in 5.3. >>>> >>>> 5.   Class MyMorph>> processEvent: anEvent using: anIgnoredDispatcher >>>> is a regular event handler in 3.10.2. In 5.3, it is a filter, and its >>>> execution never stops. >>>> >>> >>> After 60 years in programming, 42 of them in Smalltalk, and the last 20 in >>> Squeak, I have reached the end of my patience and reluctantly have to quit >>> Squeak programming. It is truly a sad day. >>> >>> Have fun and Goodbye, >>> --Trygve >>> >>> Trygve Don't say Goodbye As one of 3.10 makers , I'm proud still you use it. And as one of the admirers of you work also I'm sad. Squeak these days is a cat bag. That don't means is unusable. I try to port Baby to modern Squeak and fail. Maybe if join forces ? To all Squeakers my pray to help in this. A BabyIDE return task force. Edgar @morplenauta From marcel.taeumel at hpi.de Thu Aug 13 11:21:29 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 13 Aug 2020 13:21:29 +0200 Subject: [squeak-dev] FFI and mpfr calls in squeak In-Reply-To: References: Message-ID: Hi Lawson. >  I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? You don't. Your operating system does that for you. Well, the same lookup rules for that dependent library apply, I suppose. Do you have the gmp library installed in your system? Yes, not having all dependent libraries does raise that "external module not found" error, too. It can be confusing. Working with FFI requires knowledge about working with shared libraries in your operating system. It's one of those "leaky abstractions" where Squeak is -- understandably -- not able to hold your hand for all kinds of configurations out there. :-) You can try using a debug-build VM, which produces a more descriptive error log. Best, Marcel Am 13.08.2020 12:11:53 schrieb LawsonEnglish : So I tested a simple mandelbrot set rendering algorithm using the ArbitraryPrecisionFloat package and it works just fine, but terribly slowly. So I had the idea of using mpfr via FFI and find that I can’t even begin. I’m getting the dreaded External module not found error and just can’t get rid of it. I thought I was taking the easy route and simply copying the mpfr library into the Squeak all-in-one Resources directory but no matter what I try, that error pops up. initPrecision: aDefaultPrecision “initialize default precision" ^self externalCallFailed This is roughly the “hello world” of using mpfr, I thought, but can’t even do that. Now, waiting in the wings is a bigger problem, I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? Compile both libraries into a single target? (yikes!). That might be an issue later on, but the impression I’m getting is that squeak simply can’t find libmpfr.6.dylib, so errors that result from calling a second library from the first haven’t even popped up yet. Squeak5.3-19435-64bit, Mac OS X 10.15.6 Thanks Lawson -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Thu Aug 13 11:35:05 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Thu, 13 Aug 2020 13:35:05 +0200 Subject: [squeak-dev] FFI and mpfr calls in squeak In-Reply-To: References: Message-ID: <901A901B-B418-4C3D-BDD6-8338D9E59BA3@gmx.de> Hi > On 13.08.2020, at 13:21, Marcel Taeumel wrote: > > Hi Lawson. > > > I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? > > You don't. Your operating system does that for you. Well, the same lookup rules for that dependent library apply, I suppose. Do you have the gmp library installed in your system? > > Yes, not having all dependent libraries does raise that "external module not found" error, too. It can be confusing. > > Working with FFI requires knowledge about working with shared libraries in your operating system. It's one of those "leaky abstractions" where Squeak is -- understandably -- not able to hold your hand for all kinds of configurations out there. :-) > > You can try using a debug-build VM, which produces a more descriptive error log. also, try 'otool -L ' on the library you are trying to load. > > Best, > Marcel >> Am 13.08.2020 12:11:53 schrieb LawsonEnglish : >> >> So I tested a simple mandelbrot set rendering algorithm using the ArbitraryPrecisionFloat package and it works just fine, but terribly slowly. >> >> So I had the idea of using mpfr via FFI and find that I can’t even begin. How did you install mpfr? >> >> I’m getting the dreaded External module not found error and just can’t get rid of it. >> >> I thought I was taking the easy route and simply copying the mpfr library into the Squeak all-in-one Resources directory but no matter what I try, that error pops up. >> >> >> initPrecision: aDefaultPrecision >> “initialize default precision" >> >> >> ^self externalCallFailed >> >> This is roughly the “hello world” of using mpfr, I thought, but can’t even do that. >> >> Now, waiting in the wings is a bigger problem, I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? Compile both libraries into a single target? (yikes!). >> >> That might be an issue later on, but the impression I’m getting is that squeak simply can’t find libmpfr.6.dylib, so errors that result from calling a second library from the first haven’t even popped up yet. >> >> >> Squeak5.3-19435-64bit, Mac OS X 10.15.6 Note that MacOS changes rapidly these days and we might simply have not catched up with the newest nonsense of Apple . . . Best regards -Tobias >> >> >> Thanks >> >> >> Lawson >> > From LEnglish5 at cox.net Thu Aug 13 21:15:56 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Thu, 13 Aug 2020 14:15:56 -0700 Subject: [squeak-dev] FFI and mpfr calls in squeak In-Reply-To: References: Message-ID: Yes, thanks. I’ve created a very simple test app using mpfr. However, in xcode, at least, I have to explicitly link in both libgmp.dylib and libmpfr.dylib , which are both aliases pointing to the actual libriaries containing the code. ALL the libraries of all types created by the MacPort and put into the macport directory have been copied into the resources via duplication rather than simply moving aliases around. I first referred to “libmpfr.dylib” — which is an aliias — but starting using libmpfr.6.dylib (what the alias points to) on the outside chance that it was the alias causing problems. I don’t see how the references to code in the gmp dylib found in the mpfr dylib are going to automatically resolve if xcode requires one to explicitly link both dylibs in order for something to compile and run. . My next test is to compile some absolutely trivial library without external references and see if I can get that to work. Thanks for your input. L > On Aug 13, 2020, at 4:21 AM, Marcel Taeumel wrote: > > Hi Lawson. > > > I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? > > You don't. Your operating system does that for you. Well, the same lookup rules for that dependent library apply, I suppose. Do you have the gmp library installed in your system? > > Yes, not having all dependent libraries does raise that "external module not found" error, too. It can be confusing. > > Working with FFI requires knowledge about working with shared libraries in your operating system. It's one of those "leaky abstractions" where Squeak is -- understandably -- not able to hold your hand for all kinds of configurations out there. :-) > > You can try using a debug-build VM, which produces a more descriptive error log. > > Best, > Marcel >> Am 13.08.2020 12:11:53 schrieb LawsonEnglish : >> >> So I tested a simple mandelbrot set rendering algorithm using the ArbitraryPrecisionFloat package and it works just fine, but terribly slowly. >> >> So I had the idea of using mpfr via FFI and find that I can’t even begin. >> >> I’m getting the dreaded External module not found error and just can’t get rid of it. >> >> I thought I was taking the easy route and simply copying the mpfr library into the Squeak all-in-one Resources directory but no matter what I try, that error pops up. >> >> >> initPrecision: aDefaultPrecision >> “initialize default precision" >> >> >> ^self externalCallFailed >> >> This is roughly the “hello world” of using mpfr, I thought, but can’t even do that. >> >> Now, waiting in the wings is a bigger problem, I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? Compile both libraries into a single target? (yikes!). >> >> That might be an issue later on, but the impression I’m getting is that squeak simply can’t find libmpfr.6.dylib, so errors that result from calling a second library from the first haven’t even popped up yet. >> >> >> Squeak5.3-19435-64bit, Mac OS X 10.15.6 >> >> >> Thanks >> >> >> Lawson >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From LEnglish5 at cox.net Thu Aug 13 22:10:17 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Thu, 13 Aug 2020 15:10:17 -0700 Subject: [squeak-dev] FFI and mpfr calls in squeak In-Reply-To: References: Message-ID: You are correct and i figured out my problem. The mpfr dylib has hard-coded references to the libgmp.dylib that was in the original directory that macports compiled the mpfr.dylib into. I’ll need to do craig latta’s solution of allowing that library to work, OR redirect macports to compile into the Resources directory. This is going to make using Macports installed stuff rather difficult to use,m at least on Mac OS. Unless it is possible to tweak the dylib to redirect to the Resourses directory… And the answer is: not easily: http://lessons.livecode.com/m/4071/l/15029-linking-an-osx-external-bundle-with-a-dylib-library I’d have to figure out to manually compile the code and specify the build options at levels that aren’t exaclty relevent to my vision of a hello world implementation. (so much for sticking my toe in the water while recovering from a 5 year, near-fatal illness). Thanks for your advice, and you were spot on in what you thought was going on. Macports hardcodes the mpfr dylib to only work in that directory, and only look for the external gmp dylib in the same directory. libmpfr.6.dylib: /opt/local/lib/libmpfr.6.dylib (compatibility version 7.0.0, current version 7.2.0) /opt/local/lib/libgmp.10.dylib (compatibility version 15.0.0, current version 15.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) L > On Aug 13, 2020, at 4:21 AM, Marcel Taeumel wrote: > > Hi Lawson. > > > I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? > > You don't. Your operating system does that for you. Well, the same lookup rules for that dependent library apply, I suppose. Do you have the gmp library installed in your system? > > Yes, not having all dependent libraries does raise that "external module not found" error, too. It can be confusing. > > Working with FFI requires knowledge about working with shared libraries in your operating system. It's one of those "leaky abstractions" where Squeak is -- understandably -- not able to hold your hand for all kinds of configurations out there. :-) > > You can try using a debug-build VM, which produces a more descriptive error log. > > Best, > Marcel >> Am 13.08.2020 12:11:53 schrieb LawsonEnglish : >> >> So I tested a simple mandelbrot set rendering algorithm using the ArbitraryPrecisionFloat package and it works just fine, but terribly slowly. >> >> So I had the idea of using mpfr via FFI and find that I can’t even begin. >> >> I’m getting the dreaded External module not found error and just can’t get rid of it. >> >> I thought I was taking the easy route and simply copying the mpfr library into the Squeak all-in-one Resources directory but no matter what I try, that error pops up. >> >> >> initPrecision: aDefaultPrecision >> “initialize default precision" >> >> >> ^self externalCallFailed >> >> This is roughly the “hello world” of using mpfr, I thought, but can’t even do that. >> >> Now, waiting in the wings is a bigger problem, I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? Compile both libraries into a single target? (yikes!). >> >> That might be an issue later on, but the impression I’m getting is that squeak simply can’t find libmpfr.6.dylib, so errors that result from calling a second library from the first haven’t even popped up yet. >> >> >> Squeak5.3-19435-64bit, Mac OS X 10.15.6 >> >> >> Thanks >> >> >> Lawson >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From LEnglish5 at cox.net Thu Aug 13 22:19:38 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Thu, 13 Aug 2020 15:19:38 -0700 Subject: [squeak-dev] FFI and mpfr calls in squeak In-Reply-To: <901A901B-B418-4C3D-BDD6-8338D9E59BA3@gmx.de> References: <901A901B-B418-4C3D-BDD6-8338D9E59BA3@gmx.de> Message-ID: <7EDB88D8-EADA-4EDB-8C4F-7A7208E6145A@cox.net> That otool command told me what was wrong: libmpfr.6.dylib: /opt/local/lib/libmpfr.6.dylib (compatibility version 7.0.0, current version 7.2.0) /opt/local/lib/libgmp.10.dylib (compatibility version 15.0.0, current version 15.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) Macports hardcodes the directory that the lib will run in and the directory that it looks for the external dylib in. I might be able to coerce Squeak to execute libmpfr.6.dylib to execute in the Resources directory, but the external lib MUST be in the original directory anyway. My xcode-fu isn’t at the level (at all) to grab the source and compile it with options that redirect everything to work in the Resources directory, so’ll I need to use Craig Latta’s solution of pointing the directory path to the right library directory rather than the easier thing of copying the libraries into the Resources directory. L > On Aug 13, 2020, at 4:35 AM, Tobias Pape wrote: > > Hi > >> On 13.08.2020, at 13:21, Marcel Taeumel wrote: >> >> Hi Lawson. >> >>> I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? >> >> You don't. Your operating system does that for you. Well, the same lookup rules for that dependent library apply, I suppose. Do you have the gmp library installed in your system? >> >> Yes, not having all dependent libraries does raise that "external module not found" error, too. It can be confusing. >> >> Working with FFI requires knowledge about working with shared libraries in your operating system. It's one of those "leaky abstractions" where Squeak is -- understandably -- not able to hold your hand for all kinds of configurations out there. :-) >> >> You can try using a debug-build VM, which produces a more descriptive error log. > > also, try 'otool -L ' on the library you are trying to load. > >> >> Best, >> Marcel >>> Am 13.08.2020 12:11:53 schrieb LawsonEnglish : >>> >>> So I tested a simple mandelbrot set rendering algorithm using the ArbitraryPrecisionFloat package and it works just fine, but terribly slowly. >>> >>> So I had the idea of using mpfr via FFI and find that I can’t even begin. > > How did you install mpfr? > >>> >>> I’m getting the dreaded External module not found error and just can’t get rid of it. >>> >>> I thought I was taking the easy route and simply copying the mpfr library into the Squeak all-in-one Resources directory but no matter what I try, that error pops up. >>> >>> >>> initPrecision: aDefaultPrecision >>> “initialize default precision" >>> >>> >>> ^self externalCallFailed >>> >>> This is roughly the “hello world” of using mpfr, I thought, but can’t even do that. >>> >>> Now, waiting in the wings is a bigger problem, I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? Compile both libraries into a single target? (yikes!). >>> >>> That might be an issue later on, but the impression I’m getting is that squeak simply can’t find libmpfr.6.dylib, so errors that result from calling a second library from the first haven’t even popped up yet. >>> >>> >>> Squeak5.3-19435-64bit, Mac OS X 10.15.6 > > Note that MacOS changes rapidly these days and we might simply have not catched up with the newest nonsense of Apple . . . > > Best regards > -Tobias > > > >>> >>> >>> Thanks >>> >>> >>> Lawson >>> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Fri Aug 14 06:39:59 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Fri, 14 Aug 2020 08:39:59 +0200 Subject: [squeak-dev] FFI and mpfr calls in squeak In-Reply-To: References: Message-ID: <1A143443-E6D6-4887-92C2-B1248D813F51@gmx.de> > On 14.08.2020, at 00:10, LawsonEnglish wrote: > > You are correct and i figured out my problem. The mpfr dylib has hard-coded references to the libgmp.dylib that was in the original directory that macports compiled the mpfr.dylib into. I’ll need to do craig latta’s solution of allowing that library to work, OR redirect macports to compile into the Resources directory. > > This is going to make using Macports installed stuff rather difficult to use,m at least on Mac OS. > > Unless it is possible to tweak the dylib to redirect to the Resourses directory… Yes, its called install_name_tool(1) change dynamic shared library install names > > And the answer is: not easily: http://lessons.livecode.com/m/4071/l/15029-linking-an-osx-external-bundle-with-a-dylib-library > > I’d have to figure out to manually compile the code and specify the build options at levels that aren’t exaclty relevent to my vision of a hello world implementation. > > (so much for sticking my toe in the water while recovering from a 5 year, near-fatal illness). (Sorry, If you mean that literally, all the best for your recovery) > > Thanks for your advice, and you were spot on in what you thought was going on. Macports hardcodes the mpfr dylib to only work in that directory, and only look for the external gmp dylib in the same directory. > > libmpfr.6.dylib: > /opt/local/lib/libmpfr.6.dylib (compatibility version 7.0.0, current version 7.2.0) > /opt/local/lib/libgmp.10.dylib (compatibility version 15.0.0, current version 15.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) That's how most dylibs work :/ -t > > L > > >> On Aug 13, 2020, at 4:21 AM, Marcel Taeumel wrote: >> >> Hi Lawson. >> >> > I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? >> >> You don't. Your operating system does that for you. Well, the same lookup rules for that dependent library apply, I suppose. Do you have the gmp library installed in your system? >> >> Yes, not having all dependent libraries does raise that "external module not found" error, too. It can be confusing. >> >> Working with FFI requires knowledge about working with shared libraries in your operating system. It's one of those "leaky abstractions" where Squeak is -- understandably -- not able to hold your hand for all kinds of configurations out there. :-) >> >> You can try using a debug-build VM, which produces a more descriptive error log. >> >> Best, >> Marcel >>> Am 13.08.2020 12:11:53 schrieb LawsonEnglish : >>> >>> So I tested a simple mandelbrot set rendering algorithm using the ArbitraryPrecisionFloat package and it works just fine, but terribly slowly. >>> >>> So I had the idea of using mpfr via FFI and find that I can’t even begin. >>> >>> I’m getting the dreaded External module not found error and just can’t get rid of it. >>> >>> I thought I was taking the easy route and simply copying the mpfr library into the Squeak all-in-one Resources directory but no matter what I try, that error pops up. >>> >>> >>> initPrecision: aDefaultPrecision >>> “initialize default precision" >>> >>> >>> ^self externalCallFailed >>> >>> This is roughly the “hello world” of using mpfr, I thought, but can’t even do that. >>> >>> Now, waiting in the wings is a bigger problem, I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? Compile both libraries into a single target? (yikes!). >>> >>> That might be an issue later on, but the impression I’m getting is that squeak simply can’t find libmpfr.6.dylib, so errors that result from calling a second library from the first haven’t even popped up yet. >>> >>> >>> Squeak5.3-19435-64bit, Mac OS X 10.15.6 >>> >>> >>> Thanks >>> >>> >>> Lawson >>> >> > > From Das.Linux at gmx.de Fri Aug 14 06:40:07 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Fri, 14 Aug 2020 08:40:07 +0200 Subject: [squeak-dev] FFI and mpfr calls in squeak In-Reply-To: References: Message-ID: <469B863C-D9F0-4AD7-8A42-7548AF9F4DD4@gmx.de> Hi > On 13.08.2020, at 23:15, LawsonEnglish wrote: > > Yes, thanks. I’ve created a very simple test app using mpfr. However, in xcode, at least, I have to explicitly link in both libgmp.dylib and libmpfr.dylib , which are both aliases pointing to the actual libriaries containing the code. > > ALL the libraries of all types created by the MacPort and put into the macport directory have been copied into the resources via duplication rather than simply moving aliases around. > > I first referred to “libmpfr.dylib” — which is an aliias — but starting using libmpfr.6.dylib (what the alias points to) on the outside chance that it was the alias causing problems. > > I don’t see how the references to code in the gmp dylib found in the mpfr dylib are going to automatically resolve if xcode requires one to explicitly link both dylibs in order for something to compile and run. > Linking is different from runtime-loading. If you show me the test-app code, I certainly can give you the way FFI would do things and show why things are as they are :) > . > > My next test is to compile some absolutely trivial library without external references and see if I can get that to work. That's a good start in any case :) Best regards -Tobias > > Thanks for your input. > > L > > > >> On Aug 13, 2020, at 4:21 AM, Marcel Taeumel wrote: >> >> Hi Lawson. >> >>> I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? >> >> You don't. Your operating system does that for you. Well, the same lookup rules for that dependent library apply, I suppose. Do you have the gmp library installed in your system? >> >> Yes, not having all dependent libraries does raise that "external module not found" error, too. It can be confusing. >> >> Working with FFI requires knowledge about working with shared libraries in your operating system. It's one of those "leaky abstractions" where Squeak is -- understandably -- not able to hold your hand for all kinds of configurations out there. :-) >> >> You can try using a debug-build VM, which produces a more descriptive error log. >> >> Best, >> Marcel >>> Am 13.08.2020 12:11:53 schrieb LawsonEnglish : >>> >>> So I tested a simple mandelbrot set rendering algorithm using the ArbitraryPrecisionFloat package and it works just fine, but terribly slowly. >>> >>> So I had the idea of using mpfr via FFI and find that I can’t even begin. >>> >>> I’m getting the dreaded External module not found error and just can’t get rid of it. >>> >>> I thought I was taking the easy route and simply copying the mpfr library into the Squeak all-in-one Resources directory but no matter what I try, that error pops up. >>> >>> >>> initPrecision: aDefaultPrecision >>> “initialize default precision" >>> >>> >>> ^self externalCallFailed >>> >>> This is roughly the “hello world” of using mpfr, I thought, but can’t even do that. >>> >>> Now, waiting in the wings is a bigger problem, I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? Compile both libraries into a single target? (yikes!). >>> >>> That might be an issue later on, but the impression I’m getting is that squeak simply can’t find libmpfr.6.dylib, so errors that result from calling a second library from the first haven’t even popped up yet. >>> >>> >>> Squeak5.3-19435-64bit, Mac OS X 10.15.6 >>> >>> >>> Thanks >>> >>> >>> Lawson >>> >> > > From Das.Linux at gmx.de Fri Aug 14 06:45:17 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Fri, 14 Aug 2020 08:45:17 +0200 Subject: [squeak-dev] FFI and mpfr calls in squeak In-Reply-To: <7EDB88D8-EADA-4EDB-8C4F-7A7208E6145A@cox.net> References: <901A901B-B418-4C3D-BDD6-8338D9E59BA3@gmx.de> <7EDB88D8-EADA-4EDB-8C4F-7A7208E6145A@cox.net> Message-ID: <6F80404C-EB17-4AC6-B1FF-800FCE3A9275@gmx.de> > On 14.08.2020, at 00:19, LawsonEnglish wrote: > > That otool command told me what was wrong: > > libmpfr.6.dylib: > /opt/local/lib/libmpfr.6.dylib (compatibility version 7.0.0, current version 7.2.0) > /opt/local/lib/libgmp.10.dylib (compatibility version 15.0.0, current version 15.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) > > Macports hardcodes the directory that the lib will run in and the directory that it looks for the external dylib in. > > I might be able to coerce Squeak to execute libmpfr.6.dylib to execute in the Resources directory, but the external lib MUST be in the original directory anyway. > > My xcode-fu isn’t at the level (at all) to grab the source and compile it with options that redirect everything to work in the Resources directory, so’ll I need to use Craig Latta’s solution of pointing the directory path to the right library directory rather than the easier thing of copying the libraries into the Resources directory. You can start the Squeak binary with DYLD_LIBRARY_PATH="/opt/local/lib/" and see if that works. (Caveat Lector: 10.15 tightened the thumb screws, so that _might_ fail) Also, a typical deployment thing is indeed: - copy all the necessary dylibs to Resources - use install_name_tool to change the respective names and such to @rpath names Please read the manpage for dyld(1), especially the end for @executable_path/@loader_path/@rpath :) This will help to understand why the dynamic loading might need these names that are shown with otool Best regards -Tobias > > > L > >> On Aug 13, 2020, at 4:35 AM, Tobias Pape wrote: >> >> Hi >> >>> On 13.08.2020, at 13:21, Marcel Taeumel wrote: >>> >>> Hi Lawson. >>> >>>> I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? >>> >>> You don't. Your operating system does that for you. Well, the same lookup rules for that dependent library apply, I suppose. Do you have the gmp library installed in your system? >>> >>> Yes, not having all dependent libraries does raise that "external module not found" error, too. It can be confusing. >>> >>> Working with FFI requires knowledge about working with shared libraries in your operating system. It's one of those "leaky abstractions" where Squeak is -- understandably -- not able to hold your hand for all kinds of configurations out there. :-) >>> >>> You can try using a debug-build VM, which produces a more descriptive error log. >> >> also, try 'otool -L ' on the library you are trying to load. >> >>> >>> Best, >>> Marcel >>>> Am 13.08.2020 12:11:53 schrieb LawsonEnglish : >>>> >>>> So I tested a simple mandelbrot set rendering algorithm using the ArbitraryPrecisionFloat package and it works just fine, but terribly slowly. >>>> >>>> So I had the idea of using mpfr via FFI and find that I can’t even begin. >> >> How did you install mpfr? >> >>>> >>>> I’m getting the dreaded External module not found error and just can’t get rid of it. >>>> >>>> I thought I was taking the easy route and simply copying the mpfr library into the Squeak all-in-one Resources directory but no matter what I try, that error pops up. >>>> >>>> >>>> initPrecision: aDefaultPrecision >>>> “initialize default precision" >>>> >>>> >>>> ^self externalCallFailed >>>> >>>> This is roughly the “hello world” of using mpfr, I thought, but can’t even do that. >>>> >>>> Now, waiting in the wings is a bigger problem, I think: the mpfr library uses the gmp library. So how does one do THAT with squeak? Compile both libraries into a single target? (yikes!). >>>> >>>> That might be an issue later on, but the impression I’m getting is that squeak simply can’t find libmpfr.6.dylib, so errors that result from calling a second library from the first haven’t even popped up yet. >>>> >>>> >>>> Squeak5.3-19435-64bit, Mac OS X 10.15.6 >> >> Note that MacOS changes rapidly these days and we might simply have not catched up with the newest nonsense of Apple . . . >> >> Best regards >> -Tobias >> >> >> >>>> >>>> >>>> Thanks >>>> >>>> >>>> Lawson >>>> >>> >> >> >> > > From trygver at ifi.uio.no Fri Aug 14 09:01:28 2020 From: trygver at ifi.uio.no (Trygve Reenskaug) Date: Fri, 14 Aug 2020 11:01:28 +0200 Subject: [squeak-dev] A Sad Day In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: Hi Marcel, I am 90, and decided I did not want to spend the rest of my days with a Squeak I had no hope of understanding. That was the reason behind my goodbye-message where I was endeavoring to be as concrete and non-emotional as I possibly could. I then put everything Squeak in cold storage and picked up my life with other activities. Unfortunately, you wrote:  Class MyConnector>> processEvent: anEvent using: anIgnoredDispatcher is a regular event handler in 3.10.2. In 5.3, it is a filter, and its execution never stops. That's just not true. I am deeply offended because you accuse me of lying. I reluctantly had to retrieve Squeak from its storage yesterday and spend most of the night awake trying to formulate a non-emotional answer. This is the result: START FACTS My Squeak Reverse Engineering program (SRE)  lets me build a diagram with nodes and connectors. I add new nodes interactively and the connectors are added automatically. The connectors behave as expected with the redbutton letting me add breakpoints to a connector line and the yellowbutton opens a menu as usual. SRE has been working for many years under Squeak 3.10.2 and has proven very useful. I have copied and compiled the SRE classes into Squeak 5.3. I can still build a diagram with its nodes and connectors *BUT the image freezes immediately if the cursor touches a connector*. This anomaly is consistently reproducible and is a clear bug. I WAS NOT LYING! END FACTS I tried to debug the program. It was not easy because the normal debugging tools do not work in this case. My tentative findings were: 1) The first error is a MNU: Your system believes my connector object is an event, which is isn't. 2) /MyConnector>> processEvent:using:/ is called from /MorphicEventDispatcher/, differently in the two releases: 3.10.2     MorphicEventDispatcher>>dispatchDefault: anEvent with: aMorph 5.3          MorphicEventDispatcher>>dispatchEvent: anEvent toSubmorphsOf: aMorph I have copied the 2 methods below. The suspicious message is in 5.3: /f//ilteredEvent := child //processEvent: localEvent //using: self. / This assignment to a filter seems to be the root of the problem. *3.10.2>>**MorphicEventDispatcher>>**dispatchDefault: anEvent with: aMorph*     "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event."     | localEvt index child morphs inside |     "See if we're fully outside aMorphs bounds"     (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside"     "Traverse children"     index _ 1.     morphs _ aMorph submorphs.     inside _ false.     [index <= morphs size] whileTrue:[         child _ morphs at: index.         localEvt _ anEvent transformedBy: (child transformedFrom: aMorph).         (/*child processEvent: localEvt using: self)*/ == #rejected ifFalse:[             "Not rejected. The event was in some submorph of the receiver"             inside _ true.             localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt].             index _ morphs size. "break"         ].         index _ index + 1.     ].     "Check for being inside the receiver"     inside ifFalse:[inside _ aMorph containsPoint: anEvent position event: anEvent].     inside ifTrue:[^aMorph handleEvent: anEvent].     ^#rejected and *5,3>>MorphicEventDispatcher>>dispatchEvent: anEvent toSubmorphsOf: aMorph*     "Dispatch the given event to the submorphs of the given morph. For coordinate transformations, work only with copies. Either return the given event or a copy of any filtered event to employ immutability to some extent. --- PRIVATE!"     | localEvent filteredEvent |     aMorph submorphsDo: [:child | localEvent := anEvent transformedBy: (child transformedFrom: aMorph). /*filteredEvent :=*//*child *//*processEvent: localEvent *//*using: self. "use same dispatcher"*/         filteredEvent == #rejected ifFalse: [ "some event or #rejected symbol"             self flag: #overlappingChildren. "mt: We cannot give two overlapping siblings the chance to handle the event!"             ^ self nextFromOriginal: anEvent local: localEvent filtered: filteredEvent]].     ^ #rejected The 5.3 version assigns the result of MyConnector>> processEvent:using: to a variable called /filteredEvent/. Nothing like that happens in 3.10.2, yet you claim that /"The dispatcher is still dispatching as it was in Squeak 3.10.2"/. Since /MyConnector>> processEvent:using:/ has never returned an event, the program is doomed to fail. To avoid any further problems, I repeat that I am reporting to the best of my ability what I have experienced with a real program running in 2 real Squeak releases on real hardware. I also trust that the 2 methods i have quoted exist in the release images even though I have copied them from one of my debugging images. I hope I can return everything Squeak back to its cold storage and that it will stay there. Have fun and goodbye --Trygve On 2020-08-13 09:59, Marcel Taeumel wrote: > Hi Trygve. > > > Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 methods > in 5.3. > > Finally, we managed to improve modularity of Squeak's event handling > by assembling -- once scattered -- methods and logic in a place where > it can be found and understood. Of course, the number of methods in a > class can go up in the process. What you describe as "additional > bloat" is clearly a revelation of already existing complexity. > > Since the plain number of methods is rather unhelpful to assess code > readability, I wonder whether there are better names we can use to > guide programmers when exploring MorphicEventDispatcher, its > protocols, and methods. > > > Class /MyMorph>> processEvent: anEvent using: anIgnoredDispatcher /is > a regular event handler in 3.10.2. In 5.3, it is a filter, and its > execution never stops. > > That's just not true. The dispatcher is still dispatching as it was in > Squeak 3.10.2. Event filters were added as a mechanism to tackle the > existing mis-use of event listeners. The filter mechanism uses > patterns that are already existing in the Squeak system. Yes, there is > still room for improvement regarding its modularity. > > *** > > We need better ways to assess the image quality. Phrases such as > "unbelievable image bloat", "many thousands of classes", etc. are not > helpful at all. Such a perspective ignores incidental vs. accidental > complexity. It also ignores the role of tools in such a live and > exploratory programming system. > > We need better ways to look beyond the source code. Of course, we > strive for a clean, compact, understandable system. However, that goal > must not only focus on lines of code, number of > methods/classes/packages. Programmers do not just read code to gather > understanding. They execute code, play around with objects ---> use > tools. Those tools show us the names and relationships of all kinds of > software artifacts. Those tools enable very concise, task-specific > views on rather complex systems. Those tools can help find redundancy, > clarify meaning. > > Don't get me wrong. I am always in favor of removing a class or > concept if that is not necessary. I do think twice before adding a new > class or extending the inheritance tree. > > However, just counting the number of code artifacts is not a helpful > metric to move forward. It can only be a first step in a more > throrough exploration process. > > Don't give up. Happy Squeaking! :-) > > Best, > Marcel >> >> Am 13.08.2020 09:34:39 schrieb Trygve Reenskaug : >> >> >> Dear All, >> Imagine that you bought an iPhone 20 years ago. Over the years, you >> have filled it with pictures, contacts, and other personal data. You >> now want to upgrade to iPhone SE and find that all your personal data >> are lost because there is no way to transfer your data. Very sad. >> >> The same has happened to me with Squeak. The Squeak programs I have >> written over the past 20 years are effectively lost because I can’t >> port them to a current version of Squeak. Very sad. >> >> The essence of object orientation is that objects collaborate to >> achieve a goal. I retired 20 years ago and made it my task to create >> DCI (Data-Context-Interaction), a programming paradigm that merges >> the concepts of class and collaboration. BabyIDE is a non-intrusive >> Squeak program that includes a model of DCI as well as tools for >> programming within the paradigm. BabyIDE is a kind of Dynabook, a >> personal computer for experts in all domains. Its target group could >> be department managers in business and industry; they are experts in >> running their department in collaboration with other managers. >> Another target group could be farmers; they are experts in taking >> care of their animals. A third target group could be homeowners; they >> build expertise in controlling their smart home. >> >> Squeak is more than a programming language; it is a live universe of >> collaborating objects. The shared objects on the web is also a >> universe of collaborating objects that Kevin Kelly called a /single, >> global machine/. BabyIDE extends the Squeak image into this global >> machine, making all the combined objects available for personal >> programming as illustrated below: >> >> >> >> BabyIDE is now running in Squeak 3.10.2, together with a new Squeak >> Reverse Engineering tool. I want to port my programs to Squeak 3.5 to >> benefit from its improved internet communication facilities. This >> port has been pestering me since April, but the overwhelming >> complexity of 3.5 has forced me to accept defeat. I can’t avoid >> speculating about the nature of Squeak’s current target group. It >> used to be “children of all ages.” Today, it neither includes >> children nor old Smalltalk hands like me (I wrote my first Smalltalk >> program in 1978). Stephen Pope, another veteran who also bemoans what >> is happening to Squeak, wrote in a blog: >> >> /“//The most popular systems (Squeak and Pharo) both suffer from >> unbelievable image bloat, with many thousands of classes, >> hundreds of root classes, class hierarchies with many instance >> variables in the high-level (abstract) classes, and too many >> packages with cute but meaningless (to a new-comer) names.”/ >> https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ >> >> I couldn’t agree more. A few examples: >> >> 1.Class Object defines 485 methods. This means that every Squeak >> object understands at least 485 messages. Most of them are >> irrelevant to the problem at hand, but all of them can be part of >> unexpected behavior. >> >> 2.The state of every Morph object is held in its regular instance >> variables PLUS any number of undeclared and undocumented >> variables in its /extension/, a Dictionary that may include >> another dictionary inside it. The Morph class comment: >> /“MorphExtension Allows extra properties to be stored without >> adding a storage burden to all morphs.”/ I’m more concerned about >> the burden put upon the code reader. >> >> 3.For me, the final straw was the new filtering phase added to >> Squeak’s already complex event handling mechanism. Squeak 3.5 has >> 208 new methods with ‘filter’ in their name, but there is no >> indication as to what they are for and when to use them. The >> abstract concepts of event filtering are documented, but there is >> no documentation on their reification into concrete code. The >> complexity of a basically simple mechanism has reached a new high >> far beyond the capabilities of my brain. >> >> 4.Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 >> methods in 5.3. >> >> 5.Class /MyMorph>> processEvent: anEvent using: anIgnoredDispatcher/ >> is a regular event handler in 3.10.2. In 5.3, it is a filter, and >> its execution never stops. >> >> >> After 60 years in programming, 42 of them in Smalltalk, and the last >> 20 in Squeak, I have reached the end of my patience and reluctantly >> have to quit Squeak programming. It is truly a sad day. >> >> Have fun and Goodbye, >> --Trygve >> >> -- >> >> /The essence of object orientation is that objects collaborateto >> achieve a goal. / >> Trygve Reenskaug mailto: trygver at ifi.uio.no >> >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> N-0378 Oslo http://fullOO.info >> Norway                     Tel: (+47) 468 58 625 >> > -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver at ifi.uio.no Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 468 58 625 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Fri Aug 14 09:20:46 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Fri, 14 Aug 2020 11:20:46 +0200 Subject: [squeak-dev] A Sad Day In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: Hi Trygve, I apologize for any misunderstandings here. I am not an English native speaker. It was not my intent do accuse you of lying. However, there is a difference between a bug report and an unsubstantiated rant. I did read your entire post "A Sad Day" as the latter. Whose mistake that was, I cannot tell now. Neutral, objective bug reports would read different, I suppose. > I have copied the 2 methods below. The suspicious message is in 5.3: filteredEvent := child processEvent: localEvent using: self.  This assignment to a filter seems to be the root of the problem. That's a bug then. I will investigate that. Morphs should be able to inject their own event dispatcher at any point during the dispatching. You'r observation is correct. We should fix that. > Class MyConnector>> processEvent: anEvent using: anIgnoredDispatcher is a regular event handler in 3.10.2. In 5.3, it is a filter, and its execution never stops. Reading "anIgnoredDispatcher" is misleading because that very method #processEvent:using: is actually talking to that "ignored" dispatcher. That's why I said, it's not true. It still is not true at that point in the code. However, you made a valid point as written above. I will investigate that. *** I am sorry that you had to use uppercase letters in your previous answer. You were screaming at me, I suppose. Well, it can sometimes be hard to form a substantiated, detailed answer to an abstract, high-level claim. I hope you can understand that. Sorry again. We need better ways to assess the image quality. We need better ways to post bug reports. Best, Marcel Am 14.08.2020 11:01:38 schrieb Trygve Reenskaug : Hi Marcel, I am 90, and decided I did not want to spend the rest of my days with a Squeak I had no hope of understanding. That was the reason behind my goodbye-message where I was endeavoring to be as concrete and non-emotional as I possibly could. I then put everything Squeak in cold storage and picked up my life with other activities. Unfortunately, you wrote:  Class MyConnector>> processEvent: anEvent using: anIgnoredDispatcher is a regular event handler in 3.10.2. In 5.3, it is a filter, and its execution never stops. That's just not true. I am deeply offended because you accuse me of lying. I reluctantly had to retrieve Squeak from its storage yesterday and spend most of the night awake trying to formulate a non-emotional answer. This is the result: START FACTS My Squeak Reverse Engineering program (SRE)  lets me build a diagram with nodes and connectors. I add new nodes interactively and the connectors are added automatically. The connectors behave as expected with the redbutton letting me add breakpoints to a connector line and the yellowbutton opens a menu as usual. SRE has been working for many years under Squeak 3.10.2 and has proven very useful. I have copied and compiled the SRE classes into Squeak 5.3. I can still build a diagram with its nodes and connectors BUT the image freezes immediately if the cursor touches a connector. This anomaly is consistently reproducible and is a clear bug. I WAS NOT LYING! END FACTS I tried to debug the program. It was not easy because the normal debugging tools do not work in this case. My tentative findings were: 1) The first error is a MNU: Your system believes my connector object is an event, which is isn't. 2) MyConnector>> processEvent:using: is called from MorphicEventDispatcher, differently in the two releases: 3.10.2     MorphicEventDispatcher>>dispatchDefault: anEvent with: aMorph 5.3          MorphicEventDispatcher>>dispatchEvent: anEvent toSubmorphsOf: aMorph I have copied the 2 methods below. The suspicious message is in 5.3: filteredEvent := child processEvent: localEvent using: self.  This assignment to a filter seems to be the root of the problem. 3.10.2>>MorphicEventDispatcher>>dispatchDefault: anEvent with: aMorph     "Dispatch the given event. The event will be passed to the front-most visible submorph that contains the position wrt. to the event."     | localEvt index child morphs inside |     "See if we're fully outside aMorphs bounds"     (aMorph fullBounds containsPoint: anEvent position) ifFalse:[^#rejected]. "outside"     "Traverse children"     index _ 1.     morphs _ aMorph submorphs.     inside _ false.     [index <= morphs size] whileTrue:[         child _ morphs at: index.         localEvt _ anEvent transformedBy: (child transformedFrom: aMorph).         (child processEvent: localEvt using: self) == #rejected ifFalse:[             "Not rejected. The event was in some submorph of the receiver"             inside _ true.             localEvt wasHandled ifTrue:[anEvent copyHandlerState: localEvt].             index _ morphs size. "break"         ].         index _ index + 1.     ].     "Check for being inside the receiver"     inside ifFalse:[inside _ aMorph containsPoint: anEvent position event: anEvent].     inside ifTrue:[^aMorph handleEvent: anEvent].     ^#rejected and 5,3>>MorphicEventDispatcher>>dispatchEvent: anEvent toSubmorphsOf: aMorph     "Dispatch the given event to the submorphs of the given morph. For coordinate transformations, work only with copies. Either return the given event or a copy of any filtered event to employ immutability to some extent. --- PRIVATE!"     | localEvent filteredEvent |        aMorph submorphsDo: [:child |         localEvent := anEvent transformedBy: (child transformedFrom: aMorph).         filteredEvent := child processEvent: localEvent using: self. "use same dispatcher"         filteredEvent == #rejected ifFalse: [ "some event or #rejected symbol"             self flag: #overlappingChildren. "mt: We cannot give two overlapping siblings the chance to handle the event!"                ^ self nextFromOriginal: anEvent local: localEvent filtered: filteredEvent]].     ^ #rejected The 5.3 version assigns the result of MyConnector>> processEvent:using: to a variable called filteredEvent. Nothing like that happens in 3.10.2, yet you claim that "The dispatcher is still dispatching as it was in Squeak 3.10.2". Since MyConnector>> processEvent:using: has never returned an event, the program is doomed to fail. To avoid any further problems, I repeat that I am reporting to the best of my ability what I have experienced with a real program running in 2 real Squeak releases on real hardware. I also trust that the 2 methods i have quoted exist in the release images even though I have copied them from one of my debugging images. I hope I can return everything Squeak back to its cold storage and that it will stay there. Have fun and goodbye --Trygve On 2020-08-13 09:59, Marcel Taeumel wrote: Hi Trygve. > Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 methods in 5.3. Finally, we managed to improve modularity of Squeak's event handling by assembling -- once scattered -- methods and logic in a place where it can be found and understood. Of course, the number of methods in a class can go up in the process. What you describe as "additional bloat" is clearly a revelation of already existing complexity. Since the plain number of methods is rather unhelpful to assess code readability, I wonder whether there are better names we can use to guide programmers when exploring MorphicEventDispatcher, its protocols, and methods. > Class MyMorph>> processEvent: anEvent using: anIgnoredDispatcher is a regular event handler in 3.10.2. In 5.3, it is a filter, and its execution never stops. That's just not true. The dispatcher is still dispatching as it was in Squeak 3.10.2. Event filters were added as a mechanism to tackle the existing mis-use of event listeners. The filter mechanism uses patterns that are already existing in the Squeak system. Yes, there is still room for improvement regarding its modularity. *** We need better ways to assess the image quality. Phrases such as "unbelievable image bloat", "many thousands of classes", etc. are not helpful at all. Such a perspective ignores incidental vs. accidental complexity. It also ignores the role of tools in such a live and exploratory programming system. We need better ways to look beyond the source code. Of course, we strive for a clean, compact, understandable system. However, that goal must not only focus on lines of code, number of methods/classes/packages. Programmers do not just read code to gather understanding. They execute code, play around with objects ---> use tools. Those tools show us the names and relationships of all kinds of software artifacts. Those tools enable very concise, task-specific views on rather complex systems. Those tools can help find redundancy, clarify meaning. Don't get me wrong. I am always in favor of removing a class or concept if that is not necessary. I do think twice before adding a new class or extending the inheritance tree. However, just counting the number of code artifacts is not a helpful metric to move forward. It can only be a first step in a more throrough exploration process. Don't give up. Happy Squeaking! :-) Best, Marcel Am 13.08.2020 09:34:39 schrieb Trygve Reenskaug [mailto:trygver at ifi.uio.no]: Dear All, Imagine that you bought an iPhone 20 years ago. Over the years, you have filled it with pictures, contacts, and other personal data. You now want to upgrade to iPhone SE and find that all your personal data are lost because there is no way to transfer your data. Very sad. The same has happened to me with Squeak. The Squeak programs I have written over the past 20 years are effectively lost because I can’t port them to a current version of Squeak. Very sad. The essence of object orientation is that objects collaborate to achieve a goal. I retired 20 years ago and made it my task to create DCI (Data-Context-Interaction), a programming paradigm that merges the concepts of class and collaboration. BabyIDE is a non-intrusive Squeak program that includes a model of DCI as well as tools for programming within the paradigm. BabyIDE is a kind of Dynabook, a personal computer for experts in all domains. Its target group could be department managers in business and industry; they are experts in running their department in collaboration with other managers. Another target group could be farmers; they are experts in taking care of their animals. A third target group could be homeowners; they build expertise in controlling their smart home. Squeak is more than a programming language; it is a live universe of collaborating objects. The shared objects on the web is also a universe of collaborating objects that Kevin Kelly called a single, global machine. BabyIDE extends the Squeak image into this global machine, making all the combined objects available for personal programming as illustrated below: BabyIDE is now running in Squeak 3.10.2, together with a new Squeak Reverse Engineering tool. I want to port my programs to Squeak 3.5 to benefit from its improved internet communication facilities. This port has been pestering me since April, but the overwhelming complexity of 3.5 has forced me to accept defeat. I can’t avoid speculating about the nature of Squeak’s current target group. It used to be “children of all ages.” Today, it neither includes children nor old Smalltalk hands like me (I wrote my first Smalltalk program in 1978). Stephen Pope, another veteran who also bemoans what is happening to Squeak, wrote in a blog: “The most popular systems (Squeak and Pharo) both suffer from unbelievable image bloat, with many thousands of classes, hundreds of root classes, class hierarchies with many instance variables in the high-level (abstract) classes, and too many packages with cute but meaningless (to a new-comer) names.” https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ [https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/] I couldn’t agree more. A few examples: 1.   Class Object defines 485 methods. This means that every Squeak object understands at least 485 messages. Most of them are irrelevant to the problem at hand, but all of them can be part of unexpected behavior.  2.   The state of every Morph object is held in its regular instance variables PLUS any number of undeclared and undocumented variables in its extension, a Dictionary that may include another dictionary inside it. The Morph class comment: “MorphExtension Allows extra properties to be stored without adding a storage burden to all morphs.” I’m more concerned about the burden put upon the code reader. 3.   For me, the final straw was the new filtering phase added to Squeak’s already complex event handling mechanism. Squeak 3.5 has 208 new methods with ‘filter’ in their name, but there is no indication as to what they are for and when to use them. The abstract concepts of event filtering are documented, but there is no documentation on their reification into concrete code. The complexity of a basically simple mechanism has reached a new high far beyond the capabilities of my brain. 4.   Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 methods in 5.3. 5.   Class MyMorph>> processEvent: anEvent using: anIgnoredDispatcher is a regular event handler in 3.10.2. In 5.3, it is a filter, and its execution never stops. After 60 years in programming, 42 of them in Smalltalk, and the last 20 in Squeak, I have reached the end of my patience and reluctantly have to quit Squeak programming. It is truly a sad day. Have fun and Goodbye, --Trygve -- The essence of object orientation is that objects collaborate  to achieve a goal. Trygve Reenskaug      mailto: trygver at ifi.uio.no [mailto:%20trygver at ifi.uio.no] Morgedalsvn. 5A       http://folk.uio.no/trygver/ [http://folk.uio.no/trygver/] N-0378 Oslo             http://fullOO.info [http://fullOO.info] Norway                     Tel: (+47) 468 58 625 -- The essence of object orientation is that objects collaborate  to achieve a goal. Trygve Reenskaug      mailto: trygver at ifi.uio.no [mailto:%20trygver at ifi.uio.no] Morgedalsvn. 5A       http://folk.uio.no/trygver/ [http://folk.uio.no/trygver/] N-0378 Oslo             http://fullOO.info [http://fullOO.info] Norway                     Tel: (+47) 468 58 625 -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Fri Aug 14 11:26:14 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 14 Aug 2020 11:26:14 0000 Subject: [squeak-dev] The Trunk: MorphicTests-mt.64.mcz Message-ID: Marcel Taeumel uploaded a new version of MorphicTests to project The Trunk: http://source.squeak.org/trunk/MorphicTests-mt.64.mcz ==================== Summary ==================== Name: MorphicTests-mt.64 Author: mt Time: 14 August 2020, 1:26:13.995535 pm UUID: b4766a80-6197-4c67-bbdf-063e0bbb2d23 Ancestors: MorphicTests-nice.63 Adds test about custom Morphic event dispatcher. =============== Diff against MorphicTests-nice.63 =============== Item was changed: Morph subclass: #MorphForEventTests + instanceVariableNames: 'eventsDuringCapture eventsDuringBubble eventsRejected eventsFiltered handlesMouseDown keyStrokesReceived fullFocusDispatch eventDispatcher' - instanceVariableNames: 'eventsDuringCapture eventsDuringBubble eventsRejected eventsFiltered handlesMouseDown keyStrokesReceived fullFocusDispatch' classVariableNames: '' poolDictionaries: '' category: 'MorphicTests-Events'! Item was added: + ----- Method: MorphForEventTests>>defaultEventDispatcher (in category 'events-processing') ----- + defaultEventDispatcher + + ^ self eventDispatcher ifNil: [super defaultEventDispatcher]! Item was added: + ----- Method: MorphForEventTests>>eventDispatcher (in category 'accessing') ----- + eventDispatcher + + ^ eventDispatcher! Item was added: + ----- Method: MorphForEventTests>>eventDispatcher: (in category 'accessing') ----- + eventDispatcher: anEventDispatcher + + eventDispatcher := anEventDispatcher.! Item was added: + MorphicEventDispatcher subclass: #MorphicEventDispatcherForEventTests + instanceVariableNames: 'eventsSeen morphsSeen' + classVariableNames: '' + poolDictionaries: '' + category: 'MorphicTests-Events'! Item was added: + ----- Method: MorphicEventDispatcherForEventTests>>dispatchEvent:with: (in category 'dispatching') ----- + dispatchEvent: anEvent with: aMorph + + self eventsSeen add: anEvent copy. + self morphsSeen add: aMorph. + ^ super dispatchEvent: anEvent with: aMorph! Item was added: + ----- Method: MorphicEventDispatcherForEventTests>>eventsSeen (in category 'accessing') ----- + eventsSeen + + ^ eventsSeen ifNil: [eventsSeen := OrderedCollection new]! Item was added: + ----- Method: MorphicEventDispatcherForEventTests>>morphsSeen (in category 'accessing') ----- + morphsSeen + + ^ morphsSeen ifNil: [morphsSeen := OrderedCollection new]! Item was added: + ----- Method: MorphicEventDispatcherTests>>test12CustomEventDispatcher (in category 'tests') ----- + test12CustomEventDispatcher + "Each morph can choose to use a custom event dispatcher." + + | m1 m2 | + m1 := MorphForEventTests new. + m1 eventDispatcher: MorphicEventDispatcherForEventTests new. + + m2 := MorphForEventTests new. + m2 eventDispatcher: MorphicEventDispatcherForEventTests new. + + m2 bounds: m1 bounds. + m1 addMorph: m2. "full overlap" + + m1 openInWorld: world. + + self deny: (m1 eventDispatcher eventsSeen anySatisfy: [:ea | ea isMouseDown]). + self deny: (m2 eventDispatcher eventsSeen anySatisfy: [:ea | ea isMouseDown]). + + hand handleEvent: (self redMouseDownAt: m2 center). + + self assert: (m1 eventDispatcher eventsSeen anySatisfy: [:ea | ea isMouseDown]). + self assert: (m2 eventDispatcher eventsSeen anySatisfy: [:ea | ea isMouseDown]).! From commits at source.squeak.org Fri Aug 14 11:35:33 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Fri, 14 Aug 2020 11:35:33 0000 Subject: [squeak-dev] The Trunk: Morphic-mt.1674.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1674.mcz ==================== Summary ==================== Name: Morphic-mt.1674 Author: mt Time: 14 August 2020, 1:35:28.120535 pm UUID: 9b6b3a33-4993-437b-b180-606d9be16223 Ancestors: Morphic-mt.1673 Fixes test12CustomEventDispatcher as reported: - https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ - http://forum.world.st/A-Sad-Day-tp5120519.html This also increases the robustess when loading code that overrides #processEvent: or #processEvent:using: without returning an event object but self. =============== Diff against Morphic-mt.1673 =============== Item was changed: ----- Method: MorphicEventDispatcher>>dispatchEvent:toSubmorphsOf: (in category 'support') ----- dispatchEvent: anEvent toSubmorphsOf: aMorph "Dispatch the given event to the submorphs of the given morph. For coordinate transformations, work only with copies. Either return the given event or a copy of any filtered event to employ immutability to some extent. --- PRIVATE!!" | localEvent filteredEvent | aMorph submorphsDo: [:child | localEvent := anEvent transformedBy: (child transformedFrom: aMorph). + filteredEvent := child processEvent: localEvent. + filteredEvent == #rejected ifFalse: [ "some event or #rejected symbol or any other object" + filteredEvent isMorphicEvent ifFalse: [filteredEvent := localEvent]. - filteredEvent := child - processEvent: localEvent - using: self. "use same dispatcher" - filteredEvent == #rejected ifFalse: [ "some event or #rejected symbol" self flag: #overlappingChildren. "mt: We cannot give two overlapping siblings the chance to handle the event!!" ^ self nextFromOriginal: anEvent local: localEvent filtered: filteredEvent]]. ^ #rejected! From edgardec2005 at gmail.com Fri Aug 14 11:38:56 2020 From: edgardec2005 at gmail.com (Edgar J. De Cleene) Date: Fri, 14 Aug 2020 08:38:56 -0300 Subject: [squeak-dev] Trying to help to bring BabySRE to modern Squeak In-Reply-To: Message-ID: I have it working in FunSqueak4.6-14870.image wich is 32bit and opens with old Cog 32 bit VM With Hannes we have an unfinished port in BabySRESqueak5.2alpha-18062-32bit.image DemoEllipseSRE new openInWorld raise the changing color Morph SRE object browser works SRE collaboration freezes .image , so the problem is not new. No idea if changes in VM have some effect. Edgar @morplenauta -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Fri Aug 14 11:51:42 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Fri, 14 Aug 2020 13:51:42 +0200 Subject: [squeak-dev] The Trunk: Morphic-mt.1674.mcz In-Reply-To: References: Message-ID: Hi all! I backported the fix to 5.3, 5.2, and 5.1. Best, Marcel Am 14.08.2020 13:35:45 schrieb commits at source.squeak.org : Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1674.mcz ==================== Summary ==================== Name: Morphic-mt.1674 Author: mt Time: 14 August 2020, 1:35:28.120535 pm UUID: 9b6b3a33-4993-437b-b180-606d9be16223 Ancestors: Morphic-mt.1673 Fixes test12CustomEventDispatcher as reported: - https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ - http://forum.world.st/A-Sad-Day-tp5120519.html This also increases the robustess when loading code that overrides #processEvent: or #processEvent:using: without returning an event object but self. =============== Diff against Morphic-mt.1673 =============== Item was changed: ----- Method: MorphicEventDispatcher>>dispatchEvent:toSubmorphsOf: (in category 'support') ----- dispatchEvent: anEvent toSubmorphsOf: aMorph "Dispatch the given event to the submorphs of the given morph. For coordinate transformations, work only with copies. Either return the given event or a copy of any filtered event to employ immutability to some extent. --- PRIVATE!!" | localEvent filteredEvent | aMorph submorphsDo: [:child | localEvent := anEvent transformedBy: (child transformedFrom: aMorph). + filteredEvent := child processEvent: localEvent. + filteredEvent == #rejected ifFalse: [ "some event or #rejected symbol or any other object" + filteredEvent isMorphicEvent ifFalse: [filteredEvent := localEvent]. - filteredEvent := child - processEvent: localEvent - using: self. "use same dispatcher" - filteredEvent == #rejected ifFalse: [ "some event or #rejected symbol" self flag: #overlappingChildren. "mt: We cannot give two overlapping siblings the chance to handle the event!!" ^ self nextFromOriginal: anEvent local: localEvent filtered: filteredEvent]]. ^ #rejected! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Fri Aug 14 12:28:15 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Fri, 14 Aug 2020 14:28:15 +0200 Subject: [squeak-dev] Trying to help to bring BabySRE to modern Squeak In-Reply-To: References: Message-ID: Hi Edgar. >  SRE collaboration freezes .image , so the problem is not new. Try Morphic-mt.1674 in Trunk or the backports in 5.3, 5.2, or 5.1. Is it working now? http://forum.world.st/The-Trunk-Morphic-mt-1674-mcz-tp5120542.html [http://forum.world.st/The-Trunk-Morphic-mt-1674-mcz-tp5120542.html] Best, Marcel Am 14.08.2020 13:39:12 schrieb Edgar J. De Cleene : I have it working in FunSqueak4.6-14870.image wich is 32bit and opens with old Cog 32 bit VM With Hannes we have an unfinished port in BabySRESqueak5.2alpha-18062-32bit.image DemoEllipseSRE new openInWorld raise the changing color Morph SRE object browser works SRE collaboration freezes .image , so the problem is not new. No idea if changes in VM have some effect. Edgar @morplenauta -------------- next part -------------- An HTML attachment was scrubbed... URL: From forums.jakob at resfarm.de Fri Aug 14 15:10:36 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Fri, 14 Aug 2020 17:10:36 +0200 Subject: [squeak-dev] The Trunk: Morphic-mt.1674.mcz In-Reply-To: References: Message-ID: Actually that blog post or the complaining comment by Stephen Pope do not mention this issue at all. The comment criticizes the hugeness of the class library and the naming of categories. Though I'd attribute most of the concrete points about "bloat" to Pharo and the remaining is Morphic. Marcel Taeumel schrieb am Fr., 14. Aug. 2020, 13:52: > Hi all! > > I backported the fix to 5.3, 5.2, and 5.1. > > Best, > Marcel > > Am 14.08.2020 13:35:45 schrieb commits at source.squeak.org < > commits at source.squeak.org>: > Marcel Taeumel uploaded a new version of Morphic to project The Trunk: > http://source.squeak.org/trunk/Morphic-mt.1674.mcz > > ==================== Summary ==================== > > Name: Morphic-mt.1674 > Author: mt > Time: 14 August 2020, 1:35:28.120535 pm > UUID: 9b6b3a33-4993-437b-b180-606d9be16223 > Ancestors: Morphic-mt.1673 > > Fixes test12CustomEventDispatcher as reported: > > - https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ > - http://forum.world.st/A-Sad-Day-tp5120519.html > > This also increases the robustess when loading code that overrides > #processEvent: or #processEvent:using: without returning an event object > but self. > > =============== Diff against Morphic-mt.1673 =============== > > Item was changed: > ----- Method: MorphicEventDispatcher>>dispatchEvent:toSubmorphsOf: (in > category 'support') ----- > dispatchEvent: anEvent toSubmorphsOf: aMorph > "Dispatch the given event to the submorphs of the given morph. For > coordinate transformations, work only with copies. Either return the given > event or a copy of any filtered event to employ immutability to some > extent. --- PRIVATE!!" > > | localEvent filteredEvent | > aMorph submorphsDo: [:child | > localEvent := anEvent transformedBy: (child transformedFrom: aMorph). > + filteredEvent := child processEvent: localEvent. > + filteredEvent == #rejected ifFalse: [ "some event or #rejected symbol or > any other object" > + filteredEvent isMorphicEvent ifFalse: [filteredEvent := localEvent]. > - filteredEvent := child > - processEvent: localEvent > - using: self. "use same dispatcher" > - filteredEvent == #rejected ifFalse: [ "some event or #rejected symbol" > self flag: #overlappingChildren. "mt: We cannot give two overlapping > siblings the chance to handle the event!!" > ^ self nextFromOriginal: anEvent local: localEvent filtered: > filteredEvent]]. > > ^ #rejected! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa at codefrau.net Fri Aug 14 19:42:12 2020 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Fri, 14 Aug 2020 12:42:12 -0700 Subject: [squeak-dev] A Sad Day In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: On Fri, Aug 14, 2020 at 2:31 AM Marcel Taeumel wrote: > Hi Trygve, > > I apologize for any misunderstandings here. I am not an English native > speaker. It was not my intent do accuse you of lying. > > However, there is a difference between a bug report and an unsubstantiated > rant. I did read your entire post "A Sad Day" as the latter. Whose mistake > that was, I cannot tell now. Neutral, objective bug reports would read > different, I suppose. > It was neither a bug report nor an unsubstantiated rant. It was a criticism of the complexity of all current Smalltalks. The few examples of unexpected complexity in Squeak that Trygve chose to mention are not the actual issue. No need to feel personally attacked. Having worked with a beautifully tiny system like Smalltalk-78, or even early versions of Squeak, the complexity in modern Squeak is staggering. Smalltalk used to be a system that can be fully understood by a single person - truly a personal computing system. That is no longer the case. All the functionality we added over the years comes at the price of complexity (not to mention speed). It makes the system hard to understand. It makes it hard to see the design principles. We have not found a way to eliminate, or at least hide, any of the complexity we introduced. I don't think there is a "solution" for this within the current system. We have accepted the complexity, and now we have to live with it. And we have to accept that that alienates people who are looking for simplicity and elegance. I am sad to see Trygve leave, but I do understand. He didn't even owe us an explanation. Thank you, Trygve! All the best, Vanessa -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Fri Aug 14 19:48:14 2020 From: tim at rowledge.org (tim Rowledge) Date: Fri, 14 Aug 2020 12:48:14 -0700 Subject: [squeak-dev] Metacello related(?) MCFetchBitbucketRepository class>>#cacheDirectoryPath causes dNU when saving preferences Message-ID: In a 5.3-19435 image with metacello loaded yesterday I just tried to save my preferences and caught an error. Part of the saving process involves converting PragmaPreferences to saveable plain preferences and that in turn means finding the relevant value, which in the case of MCFetchBitbucketRepository means the cacheDirectoryPath. Sadly, the implementation is ^super cacheDirectoryPath and no super class implements it. Boom. The only implementation of #cacheDirectoryPath that has a definite value is in MCGitBasedNetworkRepository class>>#cacheDirectoryPath. Since MCBitbucketRepository is a subclass of this and would thus be happy, I suspect that MCFetchBitbucketRepository being a subclass of MCFilesystemFetchOnlyRepository implies that it should in turn implement a suitable version of #cacheDirectoryPath. The whole MCFilesystemFetchOnlyRepository tree is dated fairly recently and commented as a new approach to decoupling some stuff, so I would imagine that it simply hasn't been banged on enough to catch all this stuff yet. My guess is that a simple copy of the MCGitBasedNetworkRepository class>>#cacheDirectoryPath would work here - but I'm certainly not involved enough in metacello to be an authority. It 'works' in the sense that it allows saving my preferences but whether it would work for metacello operations... no idea. I'll also note (since I have experience of it startling people on too many occasions) that MCGitBasedNetworkRepository keeps several repository cache values as class instance variables and the newer MCFilesystemFetchOnlyRepository class is keeping them as class variables. The difference can be important. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim A bad random number generator: 1, 1, 1, 1, 1, 4.33e+67, 1, 1, 1 From nicolas.cellier.aka.nice at gmail.com Fri Aug 14 20:11:29 2020 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Fri, 14 Aug 2020 22:11:29 +0200 Subject: [squeak-dev] A Sad Day In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: Hi all, But a good part of bloat and complexity came early in the 3.x serie, so it's not a new thing. For example, Object selectors size is a bit above 100 in squeak 1.x, and above 400 yet in 3.9. Also Morphic was not introduced in 5.3, and most of its complexity was here in 3.x. By construction, with the goal to be conservative (let old package work) while still introducing new tools and features, we hardly can come back to a lean image. Pharo could be relieved from this compatibility burden, but the desire to catch up outside world complexity (provide many features leveraging tech of the day), and a tendancy to over engineering (like opal) so as to have clean and powerful design will never eliminate bloat, just replace it. It remains Cuis, which is closer to this simplicity goal. Despite recent burst of features, it may be the closest to early smalltalk spirit, i wish Juan does not forget this goal. Porting BabyIDE to Cuis might not necessarily be simpler than porting to 5.3 though... it might still be worth a try if complexity matters. Nicolas Le ven. 14 août 2020 à 21:42, Vanessa Freudenberg a écrit : > On Fri, Aug 14, 2020 at 2:31 AM Marcel Taeumel > wrote: > >> Hi Trygve, >> >> I apologize for any misunderstandings here. I am not an English native >> speaker. It was not my intent do accuse you of lying. >> >> However, there is a difference between a bug report and an >> unsubstantiated rant. I did read your entire post "A Sad Day" as the >> latter. Whose mistake that was, I cannot tell now. Neutral, objective bug >> reports would read different, I suppose. >> > > It was neither a bug report nor an unsubstantiated rant. It was a > criticism of the complexity of all current Smalltalks. The few examples of > unexpected complexity in Squeak that Trygve chose to mention are not the > actual issue. No need to feel personally attacked. > > Having worked with a beautifully tiny system like Smalltalk-78, or even > early versions of Squeak, the complexity in modern Squeak is staggering. > > Smalltalk used to be a system that can be fully understood by a single > person - truly a personal computing system. That is no longer the case. > > All the functionality we added over the years comes at the price of > complexity (not to mention speed). It makes the system hard to understand. > It makes it hard to see the design principles. We have not found a way to > eliminate, or at least hide, any of the complexity we introduced. > > I don't think there is a "solution" for this within the current system. We > have accepted the complexity, and now we have to live with it. And we have > to accept that that alienates people who are looking for simplicity and > elegance. > > I am sad to see Trygve leave, but I do understand. He didn't even owe us > an explanation. Thank you, Trygve! > > All the best, > Vanessa > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlramberg at gmail.com Fri Aug 14 20:54:24 2020 From: karlramberg at gmail.com (karl ramberg) Date: Fri, 14 Aug 2020 22:54:24 +0200 Subject: [squeak-dev] A Sad Day In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: Well said, Vanessa :-) The complexity comes from people using Squeak and wanting to improve it in many directions. And managing code , graphics , user interface , faster virtual machine, networking, security etc. are hard problems which add complexity. And also the added accidental complexity on top of that. It seems systems only are simple and elegant until people start using them. One can see that as a good or bad thing. Solution to the complexity problem will probably take a few generations to solve... Best, Karl On Fri, Aug 14, 2020 at 9:42 PM Vanessa Freudenberg wrote: > On Fri, Aug 14, 2020 at 2:31 AM Marcel Taeumel > wrote: > >> Hi Trygve, >> >> I apologize for any misunderstandings here. I am not an English native >> speaker. It was not my intent do accuse you of lying. >> >> However, there is a difference between a bug report and an >> unsubstantiated rant. I did read your entire post "A Sad Day" as the >> latter. Whose mistake that was, I cannot tell now. Neutral, objective bug >> reports would read different, I suppose. >> > > It was neither a bug report nor an unsubstantiated rant. It was a > criticism of the complexity of all current Smalltalks. The few examples of > unexpected complexity in Squeak that Trygve chose to mention are not the > actual issue. No need to feel personally attacked. > > Having worked with a beautifully tiny system like Smalltalk-78, or even > early versions of Squeak, the complexity in modern Squeak is staggering. > > Smalltalk used to be a system that can be fully understood by a single > person - truly a personal computing system. That is no longer the case. > > All the functionality we added over the years comes at the price of > complexity (not to mention speed). It makes the system hard to understand. > It makes it hard to see the design principles. We have not found a way to > eliminate, or at least hide, any of the complexity we introduced. > > I don't think there is a "solution" for this within the current system. We > have accepted the complexity, and now we have to live with it. And we have > to accept that that alienates people who are looking for simplicity and > elegance. > > I am sad to see Trygve leave, but I do understand. He didn't even owe us > an explanation. Thank you, Trygve! > > All the best, > Vanessa > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Fri Aug 14 20:57:14 2020 From: tim at rowledge.org (tim Rowledge) Date: Fri, 14 Aug 2020 13:57:14 -0700 Subject: [squeak-dev] A Sad Day In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: <01AB38C5-396C-4B16-94DB-E43BBA88FE74@rowledge.org> > On 2020-08-14, at 12:42 PM, Vanessa Freudenberg wrote: > > > Smalltalk used to be a system that can be fully understood by a single person - truly a personal computing system. That is no longer the case. Yes; a long time ago when the system was smaller (ST80v2 I guess) I could basically recite the source of any method in the system from memory. But back then the image ran in 1Mb. And did very little. > > All the functionality we added over the years comes at the price of complexity (not to mention speed). It makes the system hard to understand. It makes it hard to see the design principles. We have not found a way to eliminate, or at least hide, any of the complexity we introduced. It's an ever present tension. Stuff in the default image tends to get cared for, because it's right there blowing up when you make a bad change. Too much stuff in the default image makes for irritating bloat (cough, EToys, cough). Have stuff outside the image default image (seaside, magma, metacello, etc) and it gets broken too easily unless enough people are regularly using it to notice issues. Change things to improve stuff or fix problems and you will inevitably break something else. And always, things get added that are incomplete and not totally thought out and/or not fully integrated with the existing code. Unless you can afford the time to keep track of all that is going on, every time there is a new release it will be a major effort to port forward. Skip one or two releases and you are in real trouble - which is what I suggest the root issue is here for Trygve. Trying to jump form 3.1 to 5.3 ... eek. It's almost certainly as much trouble as porting from VW8.3 to Sq5.3. However, it *can* be done, with help. I wish, oh how I wish, that we had the resources to do proper reviews before including new things and bug fixes. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Oxymorons: Exact estimate From nicolas.cellier.aka.nice at gmail.com Fri Aug 14 21:38:00 2020 From: nicolas.cellier.aka.nice at gmail.com (Nicolas Cellier) Date: Fri, 14 Aug 2020 23:38:00 +0200 Subject: [squeak-dev] A Sad Day In-Reply-To: <01AB38C5-396C-4B16-94DB-E43BBA88FE74@rowledge.org> References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <01AB38C5-396C-4B16-94DB-E43BBA88FE74@rowledge.org> Message-ID: Le ven. 14 août 2020 à 22:57, tim Rowledge a écrit : > > > > On 2020-08-14, at 12:42 PM, Vanessa Freudenberg > wrote: > > > > > > > Smalltalk used to be a system that can be fully understood by a single > person - truly a personal computing system. That is no longer the case. > > Yes; a long time ago when the system was smaller (ST80v2 I guess) I could > basically recite the source of any method in the system from memory. But > back then the image ran in 1Mb. And did very little. > > Ah same reference, I swear that I went thru each and every method in v2.3 and could master and understand what each did. In STV too, but that's cheating, the compiler was hidden ;) I can say that such thing never happened in Squeak, despite 15 years of (superficial) usage. > > > All the functionality we added over the years comes at the price of > complexity (not to mention speed). It makes the system hard to understand. > It makes it hard to see the design principles. We have not found a way to > eliminate, or at least hide, any of the complexity we introduced. > > It's an ever present tension. > > Stuff in the default image tends to get cared for, because it's right > there blowing up when you make a bad change. Too much stuff in the default > image makes for irritating bloat (cough, EToys, cough). Have stuff outside > the image default image (seaside, magma, metacello, etc) and it gets broken > too easily unless enough people are regularly using it to notice issues. > > Change things to improve stuff or fix problems and you will inevitably > break something else. And always, things get added that are incomplete and > not totally thought out and/or not fully integrated with the existing code. > > Unless you can afford the time to keep track of all that is going on, > every time there is a new release it will be a major effort to port > forward. Skip one or two releases and you are in real trouble - which is > what I suggest the root issue is here for Trygve. Trying to jump form 3.1 > to 5.3 ... eek. It's almost certainly as much trouble as porting from VW8.3 > to Sq5.3. However, it *can* be done, with help. > > I wish, oh how I wish, that we had the resources to do proper reviews > before including new things and bug fixes. > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Oxymorons: Exact estimate > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From LEnglish5 at cox.net Sat Aug 15 01:04:37 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Fri, 14 Aug 2020 18:04:37 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? Message-ID: I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. L From eliot.miranda at gmail.com Sat Aug 15 01:14:14 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 14 Aug 2020 18:14:14 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: References: Message-ID: Hi Lawson, > On Aug 14, 2020, at 6:04 PM, LawsonEnglish wrote: > > I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. > > I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. > > So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. > > Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. The FFI tests work out if the biz for me on MacOS 64-bit. The test functions are included in the FFI plugin. I haven’t tried x86/32-bit in a while but I’d be surprised if this was broken. The code is stable. > > > L > From LEnglish5 at cox.net Sat Aug 15 01:21:22 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Fri, 14 Aug 2020 18:21:22 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: References: Message-ID: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> I’m not saying it isn’t stable. However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. L > On Aug 14, 2020, at 6:14 PM, Eliot Miranda wrote: > > Hi Lawson, > >> On Aug 14, 2020, at 6:04 PM, LawsonEnglish wrote: >> >> I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. >> >> I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. >> >> So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. >> >> Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. > > The FFI tests work out if the biz for me on MacOS 64-bit. The test functions are included in the FFI plugin. I haven’t tried x86/32-bit in a while but I’d be surprised if this was broken. The code is stable. > >> >> >> L >> > From eliot.miranda at gmail.com Sat Aug 15 04:19:38 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 14 Aug 2020 21:19:38 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> References: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> Message-ID: <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> Hi Lawson, > On Aug 14, 2020, at 6:21 PM, LawsonEnglish wrote: > > I’m not saying it isn’t stable. I know. I was just saying I don’t think anything has been broken recently, so the issue is not in the FFI per se. > However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. There’s a SqueakFFIPlugin dylib (a dylib in all but name) in SqueakFFIPlugin.bundle/Contents/MacOS/SqueakFFIPlugin. That’s what the FFI actually loads. > I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. > > SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? Yes. > I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. > > WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. > > WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? Yes, and it is extremely tricky. I’ve been using libav and libffmpeg and others. I’ve found one has to examine carefully the output of otool -L and use install_name_tool to change the hard-coded paths of any other non-system Dublin’s a Bykov depends on and make sure one understands and uses @rpath. If your dylib uses any other dylib you’re going to have to do the same exploration. > > I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. Look at the vm build makefiles for macos; they do this and they can be configured to generate dylibs in a directory, etc. So first question, what’s the output of otool -L mylib (You can omit all the /System/Library ones) > L > >> On Aug 14, 2020, at 6:14 PM, Eliot Miranda wrote: >> >> Hi Lawson, >> >>>> On Aug 14, 2020, at 6:04 PM, LawsonEnglish wrote: >>> >>> I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. >>> >>> I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. >>> >>> So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. >>> >>> Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. >> >> The FFI tests work out if the biz for me on MacOS 64-bit. The test functions are included in the FFI plugin. I haven’t tried x86/32-bit in a while but I’d be surprised if this was broken. The code is stable. >> >>> >>> >>> L >>> >> > > From tim at rowledge.org Sat Aug 15 05:14:08 2020 From: tim at rowledge.org (tim Rowledge) Date: Fri, 14 Aug 2020 22:14:08 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> References: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> Message-ID: > On 2020-08-14, at 9:19 PM, Eliot Miranda wrote: > > change the hard-coded paths of any other non-system Dublin’s a Bykov depends on The what who? tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Computers are useless. They can only give you answers. From eliot.miranda at gmail.com Sat Aug 15 05:26:08 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 14 Aug 2020 22:26:08 -0700 Subject: [squeak-dev] Fwd: Has anyone gotten FFI working on squeak on a Mac lately? References: <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> Message-ID: <14D4A158-2D4D-46EF-A8B8-3479969EE400@gmail.com> Edited for clarity From: Eliot Miranda Date: August 14, 2020 at 9:19:40 PM PDT To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? Hi Lawson, > On Aug 14, 2020, at 6:21 PM, LawsonEnglish wrote: > > I’m not saying it isn’t stable. I know. I was just saying I don’t think anything has been broken recently, so the issue is not in the FFI per se. > However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. There’s a SqueakFFIPlugin dylib (a dylib in all but name) in SqueakFFIPlugin.bundle/Contents/MacOS/SqueakFFIPlugin. That’s what the FFI actually loads. > I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. > > SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? Yes. > I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. > > WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. > > WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? Yes, and it is extremely tricky. I’ve been using libav and libffmpeg and others. I’ve found one has to examine carefully the output of otool -L and use install_name_tool to change the hard-coded paths of any other non-system dylibs a dylib depends on and make sure one understands and uses @rpath. If your dylib uses any other dylib you’re going to have to do the same exploration. > I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. Look at the vm build makefiles for macos; they do this and they can be configured to generate dylibs in a directory, etc. So first question, what’s the output of otool -L mylib (You can omit all the /System/Library ones) > L > >>> On Aug 14, 2020, at 6:14 PM, Eliot Miranda wrote: >> >> Hi Lawson, >> >>>> On Aug 14, 2020, at 6:04 PM, LawsonEnglish wrote: >>> >>> I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. >>> >>> I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. >>> >>> So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. >>> >>> Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. >> >> The FFI tests work out if the biz for me on MacOS 64-bit. The test functions are included in the FFI plugin. I haven’t tried x86/32-bit in a while but I’d be surprised if this was broken. The code is stable. >> >>> >>> >>> L -------------- next part -------------- An HTML attachment was scrubbed... URL: From trygver at ifi.uio.no Sat Aug 15 07:56:01 2020 From: trygver at ifi.uio.no (Trygve Reenskaug) Date: Sat, 15 Aug 2020 09:56:01 +0200 Subject: [squeak-dev] Distributed Squeak In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> Just an idea while a car is waiting to take me on a vacation. Imagine: 1. You have a computer with many independently running images. 2. A super fast facility pass messages between the images, 3. Selected services in the release image are move out and deployed as server objects in another image. 4. Every image appears as a server offering RESTful interfaces to other images. 5. Selected packages in any repository can be downloaded, compiled, instantiated, and deployed in an image as server objects. 6. The different images can even run in different computers and use different VMs. 7. There are now two dimensions to the reuse of functionality: a) download and compile a package. b In some image, install a package and deploy it as a server object. 8. And presto: The original image is now small and manageable while the whole system can grow without increasing the complexity of the release image. In haste. This is just an idea. It's full of holes and need a lot of work done to it before it can be usable.. It's a disruptive idea, so please give it some consideration This is before you shoot it down --Trygve On 2020-08-14 22:54, karl ramberg wrote: > Well said, Vanessa :-) > > The complexity comes from people using Squeak and wanting to improve > it in many directions. > And managing code , graphics , user interface , faster virtual > machine, networking, security etc. are hard problems which add > complexity. > And also the added accidental complexity on top of that. > > It seems systems only are simple and elegant until people start using > them. > One can see that as a good or bad thing. > > Solution to the complexity problem will probably take a few > generations to solve... > > Best, > Karl > > > > On Fri, Aug 14, 2020 at 9:42 PM Vanessa Freudenberg > > wrote: > > On Fri, Aug 14, 2020 at 2:31 AM Marcel Taeumel > > wrote: > > Hi Trygve, > > I apologize for any misunderstandings here. I am not an > English native speaker. It was not my intent do accuse you of > lying. > > However, there is a difference between a bug report and an > unsubstantiated rant. I did read your entire post "A Sad Day" > as the latter. Whose mistake that was, I cannot tell now. > Neutral, objective bug reports would read different, I suppose. > > > It was neither a bug report nor an unsubstantiated rant. It was a > criticism of the complexity of all current Smalltalks. The few > examples of unexpected complexity in Squeak that Trygve chose to > mention are not the actual issue. No need to feel personally attacked. > > Having worked with a beautifully tiny system like Smalltalk-78, or > even early versions of Squeak, the complexity in modern Squeak is > staggering. > > Smalltalk used to be a system that can be fully understood by a > single person - truly a personal computing system. That is no > longer the case. > > All the functionality we added over the years comes at the price > of complexity (not to mention speed). It makes the system hard to > understand. It makes it hard to see the design principles. We have > not found a way to eliminate, or at least hide, any of the > complexity we introduced. > > I don't think there is a "solution" for this within the current > system. We have accepted the complexity, and now we have to live > with it. And we have to accept that that alienates people who are > looking for simplicity and elegance. > > I am sad to see Trygve leave, but I do understand. He didn't even > owe us an explanation. Thank you, Trygve! > > All the best, > Vanessa > > -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver at ifi.uio.no Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 468 58 625 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Das.Linux at gmx.de Sat Aug 15 08:40:17 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Sat, 15 Aug 2020 10:40:17 +0200 Subject: [squeak-dev] Distributed Squeak In-Reply-To: <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> Message-ID: <9565F959-152C-4623-BDD1-E16F5240E848@gmx.de> > On 15.08.2020, at 09:56, Trygve Reenskaug wrote: > > Just an idea while a car is waiting to take me on a vacation. Happy vacation! -t > > Imagine: > • You have a computer with many independently running images. > • A super fast facility pass messages between the images, > • Selected services in the release image are move out and deployed as server objects in another image. > • Every image appears as a server offering RESTful interfaces to other images. > • Selected packages in any repository can be downloaded, compiled, instantiated, and deployed in an image as server objects. > • The different images can even run in different computers and use different VMs. > • There are now two dimensions to the reuse of functionality: a) download and compile a package. b In some image, install a package and deploy it as a server object. > • And presto: The original image is now small and manageable while the whole system can grow without increasing the complexity of the release image. > In haste. This is just an idea. It's full of holes and need a lot of work done to it before it can be usable.. It's a disruptive idea, so please give it some consideration This is before you shoot it down > --Trygve > > > > > > On 2020-08-14 22:54, karl ramberg wrote: >> Well said, Vanessa :-) >> >> The complexity comes from people using Squeak and wanting to improve it in many directions. >> And managing code , graphics , user interface , faster virtual machine, networking, security etc. are hard problems which add complexity. >> And also the added accidental complexity on top of that. >> >> It seems systems only are simple and elegant until people start using them. >> One can see that as a good or bad thing. >> >> Solution to the complexity problem will probably take a few generations to solve... >> >> Best, >> Karl >> >> >> >> On Fri, Aug 14, 2020 at 9:42 PM Vanessa Freudenberg wrote: >> On Fri, Aug 14, 2020 at 2:31 AM Marcel Taeumel wrote: >> Hi Trygve, >> >> I apologize for any misunderstandings here. I am not an English native speaker. It was not my intent do accuse you of lying. >> >> However, there is a difference between a bug report and an unsubstantiated rant. I did read your entire post "A Sad Day" as the latter. Whose mistake that was, I cannot tell now. Neutral, objective bug reports would read different, I suppose. >> >> It was neither a bug report nor an unsubstantiated rant. It was a criticism of the complexity of all current Smalltalks. The few examples of unexpected complexity in Squeak that Trygve chose to mention are not the actual issue. No need to feel personally attacked. >> >> Having worked with a beautifully tiny system like Smalltalk-78, or even early versions of Squeak, the complexity in modern Squeak is staggering. >> >> Smalltalk used to be a system that can be fully understood by a single person - truly a personal computing system. That is no longer the case. >> >> All the functionality we added over the years comes at the price of complexity (not to mention speed). It makes the system hard to understand. It makes it hard to see the design principles. We have not found a way to eliminate, or at least hide, any of the complexity we introduced. >> >> I don't think there is a "solution" for this within the current system. We have accepted the complexity, and now we have to live with it. And we have to accept that that alienates people who are looking for simplicity and elegance. >> >> I am sad to see Trygve leave, but I do understand. He didn't even owe us an explanation. Thank you, Trygve! >> >> All the best, >> Vanessa From edgardec2005 at gmail.com Sat Aug 15 08:45:18 2020 From: edgardec2005 at gmail.com (Edgar J. De Cleene) Date: Sat, 15 Aug 2020 05:45:18 -0300 Subject: [squeak-dev] Trying to help to bring BabySRE to modern Squeak In-Reply-To: Message-ID: On 8/14/20, 9:28 AM, "Marcel Taeumel" wrote: > Hi Edgar. > >> SRE collaboration freezes .image , so the problem is not new. > > Try Morphic-mt.1674 in Trunk or the backports in 5.3, 5.2, or 5.1. Is it > working now? > http://forum.world.st/The-Trunk-Morphic-mt-1674-mcz-tp5120542.html > > > Best, > Marcel Do not work in the .image, but maybe the image is corrupt. I try in fresh 6.0 as this should be the target. Thanks for you work and be patient. We can't loose valuable people. Edgar @morplenauta From Tom.Beckmann at student.hpi.uni-potsdam.de Sat Aug 15 08:54:12 2020 From: Tom.Beckmann at student.hpi.uni-potsdam.de (Beckmann, Tom) Date: Sat, 15 Aug 2020 08:54:12 +0000 Subject: [squeak-dev] Metacello related(?) MCFetchBitbucketRepository class>>#cacheDirectoryPath causes dNU when saving preferences In-Reply-To: References: Message-ID: Thank you for the report Tim! I addressed the issue here: https://github.com/Metacello/metacello/pull/526 Your assessment was correct: during the migration I missed the preferences accessors and the importance between ClassVars and class-side InstVars in this case was also lost. The above PR fixes both issues. Best, Tom ________________________________________ From: Squeak-dev on behalf of tim Rowledge Sent: Friday, August 14, 2020 9:48:14 PM To: The general-purpose Squeak developers list Subject: [squeak-dev] Metacello related(?) MCFetchBitbucketRepository class>>#cacheDirectoryPath causes dNU when saving preferences In a 5.3-19435 image with metacello loaded yesterday I just tried to save my preferences and caught an error. Part of the saving process involves converting PragmaPreferences to saveable plain preferences and that in turn means finding the relevant value, which in the case of MCFetchBitbucketRepository means the cacheDirectoryPath. Sadly, the implementation is ^super cacheDirectoryPath and no super class implements it. Boom. The only implementation of #cacheDirectoryPath that has a definite value is in MCGitBasedNetworkRepository class>>#cacheDirectoryPath. Since MCBitbucketRepository is a subclass of this and would thus be happy, I suspect that MCFetchBitbucketRepository being a subclass of MCFilesystemFetchOnlyRepository implies that it should in turn implement a suitable version of #cacheDirectoryPath. The whole MCFilesystemFetchOnlyRepository tree is dated fairly recently and commented as a new approach to decoupling some stuff, so I would imagine that it simply hasn't been banged on enough to catch all this stuff yet. My guess is that a simple copy of the MCGitBasedNetworkRepository class>>#cacheDirectoryPath would work here - but I'm certainly not involved enough in metacello to be an authority. It 'works' in the sense that it allows saving my preferences but whether it would work for metacello operations... no idea. I'll also note (since I have experience of it startling people on too many occasions) that MCGitBasedNetworkRepository keeps several repository cache values as class instance variables and the newer MCFilesystemFetchOnlyRepository class is keeping them as class variables. The difference can be important. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim A bad random number generator: 1, 1, 1, 1, 1, 4.33e+67, 1, 1, 1 From edgardec2005 at gmail.com Sat Aug 15 09:00:08 2020 From: edgardec2005 at gmail.com (Edgar J. De Cleene) Date: Sat, 15 Aug 2020 06:00:08 -0300 Subject: [squeak-dev] Distributed Squeak In-Reply-To: <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> Message-ID: On 8/15/20, 4:56 AM, "Trygve Reenskaug" wrote: > Just an idea while a car is waiting to take me on a vacation. > > Imagine: > > 1. You have a computer with many independently running images. > 2. A super fast facility pass messages between the images, > 3. Selected services in the release image are move out and deployed as server > objects in another image. > 4. Every image appears as a server offering RESTful interfaces to other > images. > 5. Selected packages in any repository can be downloaded, compiled, > instantiated, and deployed in an image as server objects. > 6. The different images can even run in different computers and use different > VMs. > 7. > 8. There are now two dimensions to the reuse of functionality: a) download and > compile a package. b In some image, install a package and deploy it as a > server object. > 9. And presto: The original image is now small and manageable while the whole > system can grow without increasing the complexity of the release image. > In haste. This is just an idea. It's full of holes and need a lot of work > done to it before it can be usable.. It's a disruptive idea, so please give it > some consideration This is before you shoot it down > --Trygve > I point all to https://github.com/ErikOnBike/CodeParadise Erik have here some really small and IMHO is a killer. Is Pharo 8 and still can't port to Squeak. Maybe some here is interested in such thing ? Edgar @morplenauta From karlramberg at gmail.com Sat Aug 15 09:11:19 2020 From: karlramberg at gmail.com (karl ramberg) Date: Sat, 15 Aug 2020 11:11:19 +0200 Subject: [squeak-dev] Distributed Squeak In-Reply-To: <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> Message-ID: Craig Latta has been developing similar stuff for a while with Spoon and other projects: "... I’m working on my Context project, a distributed, modular, minimalist computer programming system. It’s a distributed object system with a module system (“Naiad “) and a minimal kernel (“Spoon”). " https://thiscontext.com/ Best, Karl On Sat, Aug 15, 2020 at 9:56 AM Trygve Reenskaug wrote: > Just an idea while a car is waiting to take me on a vacation. > > Imagine: > > 1. You have a computer with many independently running images. > 2. A super fast facility pass messages between the images, > 3. Selected services in the release image are move out and deployed as > server objects in another image. > 4. Every image appears as a server offering RESTful interfaces to > other images. > 5. Selected packages in any repository can be downloaded, compiled, > instantiated, and deployed in an image as server objects. > 6. The different images can even run in different computers and use > different VMs. > 7. There are now two dimensions to the reuse of functionality: a) > download and compile a package. b In some image, install a package and > deploy it as a server object. > 8. And presto: The original image is now small and manageable while > the whole system can grow without increasing the complexity of the release > image. > > In haste. This is just an idea. It's full of holes and need a lot of work > done to it before it can be usable.. It's a disruptive idea, so please give > it some consideration This is before you shoot it down > --Trygve > > > > > > On 2020-08-14 22:54, karl ramberg wrote: > > Well said, Vanessa :-) > > The complexity comes from people using Squeak and wanting to improve it in > many directions. > And managing code , graphics , user interface , faster virtual machine, > networking, security etc. are hard problems which add complexity. > And also the added accidental complexity on top of that. > > It seems systems only are simple and elegant until people start using them. > One can see that as a good or bad thing. > > Solution to the complexity problem will probably take a few generations to > solve... > > Best, > Karl > > > > On Fri, Aug 14, 2020 at 9:42 PM Vanessa Freudenberg > wrote: > >> On Fri, Aug 14, 2020 at 2:31 AM Marcel Taeumel >> wrote: >> >>> Hi Trygve, >>> >>> I apologize for any misunderstandings here. I am not an English native >>> speaker. It was not my intent do accuse you of lying. >>> >>> However, there is a difference between a bug report and an >>> unsubstantiated rant. I did read your entire post "A Sad Day" as the >>> latter. Whose mistake that was, I cannot tell now. Neutral, objective bug >>> reports would read different, I suppose. >>> >> >> It was neither a bug report nor an unsubstantiated rant. It was a >> criticism of the complexity of all current Smalltalks. The few examples of >> unexpected complexity in Squeak that Trygve chose to mention are not the >> actual issue. No need to feel personally attacked. >> >> Having worked with a beautifully tiny system like Smalltalk-78, or even >> early versions of Squeak, the complexity in modern Squeak is staggering. >> >> Smalltalk used to be a system that can be fully understood by a single >> person - truly a personal computing system. That is no longer the case. >> >> All the functionality we added over the years comes at the price of >> complexity (not to mention speed). It makes the system hard to understand. >> It makes it hard to see the design principles. We have not found a way to >> eliminate, or at least hide, any of the complexity we introduced. >> >> I don't think there is a "solution" for this within the current system. >> We have accepted the complexity, and now we have to live with it. And we >> have to accept that that alienates people who are looking for simplicity >> and elegance. >> >> I am sad to see Trygve leave, but I do understand. He didn't even owe us >> an explanation. Thank you, Trygve! >> >> All the best, >> Vanessa >> >> > > -- > > *The essence of object orientation is that objects collaborate to achieve > a goal. * > Trygve Reenskaug mailto: trygver at ifi.uio.no <%20trygver at ifi.uio.no> > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway Tel: (+47) 468 58 625 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giorgioferraris at elevensoft.it Sat Aug 15 09:55:50 2020 From: giorgioferraris at elevensoft.it (giorgio ferraris) Date: Sat, 15 Aug 2020 11:55:50 +0200 Subject: [squeak-dev] A Sad Day In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: if you go out of the commercial (and so more stable), Smalltalks, I think Cuis Smalltalk could be a nice answer to simplicity, try to give a look. They are maniacs about code reduction (less is more to the limit...) Squeak and Pharo are interesting for the new features added, but you pay the cost in term of complexity ciao giorgio On Fri, Aug 14, 2020 at 9:42 PM Vanessa Freudenberg wrote: > On Fri, Aug 14, 2020 at 2:31 AM Marcel Taeumel > wrote: > >> Hi Trygve, >> >> I apologize for any misunderstandings here. I am not an English native >> speaker. It was not my intent do accuse you of lying. >> >> However, there is a difference between a bug report and an >> unsubstantiated rant. I did read your entire post "A Sad Day" as the >> latter. Whose mistake that was, I cannot tell now. Neutral, objective bug >> reports would read different, I suppose. >> > > It was neither a bug report nor an unsubstantiated rant. It was a > criticism of the complexity of all current Smalltalks. The few examples of > unexpected complexity in Squeak that Trygve chose to mention are not the > actual issue. No need to feel personally attacked. > > Having worked with a beautifully tiny system like Smalltalk-78, or even > early versions of Squeak, the complexity in modern Squeak is staggering. > > Smalltalk used to be a system that can be fully understood by a single > person - truly a personal computing system. That is no longer the case. > > All the functionality we added over the years comes at the price of > complexity (not to mention speed). It makes the system hard to understand. > It makes it hard to see the design principles. We have not found a way to > eliminate, or at least hide, any of the complexity we introduced. > > I don't think there is a "solution" for this within the current system. We > have accepted the complexity, and now we have to live with it. And we have > to accept that that alienates people who are looking for simplicity and > elegance. > > I am sad to see Trygve leave, but I do understand. He didn't even owe us > an explanation. Thank you, Trygve! > > All the best, > Vanessa > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.l.davies at gmail.com Sat Aug 15 14:13:01 2020 From: stephen.l.davies at gmail.com (Stephen Davies) Date: Sat, 15 Aug 2020 16:13:01 +0200 Subject: [squeak-dev] A Sad Day In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: Hi, I have I think a good understanding of the principles of Smalltalk 80. But I admit I find Squeak and Pharo overwhelming - I will blame my increasing age - but Cuis I can get hold of. Of course I have no doubt that if Squeak is an "old friend" you would not willingly switch to a Smalltalk with so much less in the class library. Regards, Steve On Sat, 15 Aug 2020, 11:56 giorgio ferraris, wrote: > if you go out of the commercial (and so more stable), Smalltalks, I think > Cuis Smalltalk could be a nice answer to simplicity, try to give a look. > They are maniacs about code reduction (less is more to the limit...) > Squeak and Pharo are interesting for the new features added, but you pay > the cost in term of complexity > > ciao > > giorgio > > On Fri, Aug 14, 2020 at 9:42 PM Vanessa Freudenberg > wrote: > >> On Fri, Aug 14, 2020 at 2:31 AM Marcel Taeumel >> wrote: >> >>> Hi Trygve, >>> >>> I apologize for any misunderstandings here. I am not an English native >>> speaker. It was not my intent do accuse you of lying. >>> >>> However, there is a difference between a bug report and an >>> unsubstantiated rant. I did read your entire post "A Sad Day" as the >>> latter. Whose mistake that was, I cannot tell now. Neutral, objective bug >>> reports would read different, I suppose. >>> >> >> It was neither a bug report nor an unsubstantiated rant. It was a >> criticism of the complexity of all current Smalltalks. The few examples of >> unexpected complexity in Squeak that Trygve chose to mention are not the >> actual issue. No need to feel personally attacked. >> >> Having worked with a beautifully tiny system like Smalltalk-78, or even >> early versions of Squeak, the complexity in modern Squeak is staggering. >> >> Smalltalk used to be a system that can be fully understood by a single >> person - truly a personal computing system. That is no longer the case. >> >> All the functionality we added over the years comes at the price of >> complexity (not to mention speed). It makes the system hard to understand. >> It makes it hard to see the design principles. We have not found a way to >> eliminate, or at least hide, any of the complexity we introduced. >> >> I don't think there is a "solution" for this within the current system. >> We have accepted the complexity, and now we have to live with it. And we >> have to accept that that alienates people who are looking for simplicity >> and elegance. >> >> I am sad to see Trygve leave, but I do understand. He didn't even owe us >> an explanation. Thank you, Trygve! >> >> All the best, >> Vanessa >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kksubbu.ml at gmail.com Sat Aug 15 16:22:11 2020 From: kksubbu.ml at gmail.com (K K Subbu) Date: Sat, 15 Aug 2020 21:52:11 +0530 Subject: [squeak-dev] A Sad Day In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: <5d937770-e63f-ad39-80ed-9ab48c2cf1d3@gmail.com> On 15/08/20 1:41 am, Nicolas Cellier wrote: > But a good part of bloat and complexity came early in the 3.x serie, so > it's not a new thing. > For example, Object selectors size is a bit above 100 in squeak 1.x, and > above 400 yet in 3.9. Also Morphic was not introduced in 5.3, and most > of its complexity was here in 3.x. Good point! There was a sharp jump during 3.0-3.2 days when Morphic became the default UI and Nebraska (remote Morphic) was added. Around 1000 classes seems to be tolerance limit for personal image. Ironically, it is the very remote facility for distributed image that Trygve proposes that tipped the boat :-(. Regards .. Subbu From tim at rowledge.org Sat Aug 15 17:17:10 2020 From: tim at rowledge.org (tim Rowledge) Date: Sat, 15 Aug 2020 10:17:10 -0700 Subject: [squeak-dev] Distributed Squeak In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> Message-ID: > On 2020-08-15, at 2:11 AM, karl ramberg wrote: > > Craig Latta has been developing similar stuff for a while It's about 20 years now, IIRC. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: PNG: Pass Noxious Gas From lewis at mail.msen.com Sat Aug 15 18:36:19 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Sat, 15 Aug 2020 14:36:19 -0400 Subject: [squeak-dev] May I remove ClassBuilder>format:variable:words:pointers:weak: Message-ID: <20200815183619.GA59538@shell.msen.com> ClassBuilder>format:variable:words:pointers:weak: is obsolete and unreferenced. May I remove it, and also clean up related references in MethodFinder>>notDangerous? Asking here so as not to clutter up the inbox. Thanks, Dave From LEnglish5 at cox.net Sat Aug 15 20:35:41 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Sat, 15 Aug 2020 13:35:41 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> References: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> Message-ID: Thanks.I checked, and inded my dylib was pointing back to the directory it was created in. I’ll look at how the bundled libraries’ paths are set up and try to recreate that. Should I get it working, I foresee several new “From the very start” videos in the works, but I think I’ll need a new title for the series at this level. L > On Aug 14, 2020, at 9:19 PM, Eliot Miranda wrote: > > Hi Lawson, > >> On Aug 14, 2020, at 6:21 PM, LawsonEnglish wrote: >> >> I’m not saying it isn’t stable. > > I know. I was just saying I don’t think anything has been broken recently, so the issue is not in the FFI per se. > >> However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. > > There’s a SqueakFFIPlugin dylib (a dylib in all but name) in SqueakFFIPlugin.bundle/Contents/MacOS/SqueakFFIPlugin. That’s what the FFI actually loads. > >> I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. >> >> SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? > > Yes. > >> I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. >> >> WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. >> >> WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? > > Yes, and it is extremely tricky. I’ve been using libav and libffmpeg and others. I’ve found one has to examine carefully the output of otool -L and use install_name_tool to change the hard-coded paths of any other non-system Dublin’s a Bykov depends on and make sure one understands and uses @rpath. If your dylib uses any other dylib you’re going to have to do the same exploration. > >> >> I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. > > Look at the vm build makefiles for macos; they do this and they can be configured to generate dylibs in a directory, etc. > > So first question, what’s the output of > otool -L mylib > > (You can omit all the /System/Library ones) > >> L >> >>> On Aug 14, 2020, at 6:14 PM, Eliot Miranda wrote: >>> >>> Hi Lawson, >>> >>>>> On Aug 14, 2020, at 6:04 PM, LawsonEnglish wrote: >>>> >>>> I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. >>>> >>>> I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. >>>> >>>> So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. >>>> >>>> Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. >>> >>> The FFI tests work out if the biz for me on MacOS 64-bit. The test functions are included in the FFI plugin. I haven’t tried x86/32-bit in a while but I’d be surprised if this was broken. The code is stable. >>> >>>> >>>> >>>> L >>>> >>> >> >> > From LEnglish5 at cox.net Sat Aug 15 20:54:41 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Sat, 15 Aug 2020 13:54:41 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> References: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> Message-ID: A followup issue is that simply getting the “External module not found” error the way I do eventually caues either a freeze, or a crash on startup. That’s happened with 3 different all-in-one Squeak 5.3’s. The debug VM also eventually freezes it seems, when I left it unattended overnight after trying to run that FFI call and getting that error. So far we haven’t figured out where to put a break in the C code to halt just before that error emerges, but just getting that error enough times seems to have its own bad effects on squeak, even if it takes a while to show up. L > On Aug 14, 2020, at 9:19 PM, Eliot Miranda wrote: > > Hi Lawson, > >> On Aug 14, 2020, at 6:21 PM, LawsonEnglish wrote: >> >> I’m not saying it isn’t stable. > > I know. I was just saying I don’t think anything has been broken recently, so the issue is not in the FFI per se. > >> However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. > > There’s a SqueakFFIPlugin dylib (a dylib in all but name) in SqueakFFIPlugin.bundle/Contents/MacOS/SqueakFFIPlugin. That’s what the FFI actually loads. > >> I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. >> >> SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? > > Yes. > >> I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. >> >> WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. >> >> WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? > > Yes, and it is extremely tricky. I’ve been using libav and libffmpeg and others. I’ve found one has to examine carefully the output of otool -L and use install_name_tool to change the hard-coded paths of any other non-system Dublin’s a Bykov depends on and make sure one understands and uses @rpath. If your dylib uses any other dylib you’re going to have to do the same exploration. > >> >> I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. > > Look at the vm build makefiles for macos; they do this and they can be configured to generate dylibs in a directory, etc. > > So first question, what’s the output of > otool -L mylib > > (You can omit all the /System/Library ones) > >> L >> >>> On Aug 14, 2020, at 6:14 PM, Eliot Miranda wrote: >>> >>> Hi Lawson, >>> >>>>> On Aug 14, 2020, at 6:04 PM, LawsonEnglish wrote: >>>> >>>> I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. >>>> >>>> I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. >>>> >>>> So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. >>>> >>>> Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. >>> >>> The FFI tests work out if the biz for me on MacOS 64-bit. The test functions are included in the FFI plugin. I haven’t tried x86/32-bit in a while but I’d be surprised if this was broken. The code is stable. >>> >>>> >>>> >>>> L >>>> >>> >> >> > From asqueaker at gmail.com Sat Aug 15 22:23:35 2020 From: asqueaker at gmail.com (Chris Muller) Date: Sat, 15 Aug 2020 17:23:35 -0500 Subject: [squeak-dev] A Sad Day In-Reply-To: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> Message-ID: Trygve, I couldn't avoid my eyes getting heavy by what I learned here. I already knew I share your desire and vision for everyday people to be empowered by personal computing, and have pursued this goal for 20 years with Squeak as well. Tablets came out since then, but they didn't solve it -- they're partitioned by function (app) rather than by object, with woefully insufficient inter-domain cohesion. I still believe the paradigm of "one universe of objects" (some *personal*, some *shared*, some *internal*, some *external*) and "send a message to an object" -- if properly encapsulated and designed with sufficient empathy for *users* -- *can* be understood and embraced into an acceptable paradigm. Indeed, today's Squeak community has become a lonely place for Dynabook dreams, as it became concerned with different goals, but I haven't given up on it still being possible with a derivative of Squeak 5.3. I still have an email from you about Baby*, which I've starred, and intended to get back to you when I finally get to mount my second attack on MaUI[1]. Alas, time is a merciless teacher, I won't get to realize my fantasy to interact with you on this. However, I've now secured a copy of your whitepaper PDF, and the versions of Baby* on SqueakMap, which I look forward to exploring and learning. I don't know him personally, but have interacted with Marcel enough to believe his words were simply daring you to elicit more detail, not question your honesty. He's darn good at wrangling Squeak, whatever issue you found, it's a good bet he would be able to fix it. I hope you'll give him the benefit of the doubt. Now is your time to be at peace with the universe. Farewell. Regards, Chris Muller [1] -- http://wiki.squeak.org/squeak/3836 On Thu, Aug 13, 2020 at 2:34 AM Trygve Reenskaug wrote: > > Dear All, > Imagine that you bought an iPhone 20 years ago. Over the years, you have > filled it with pictures, contacts, and other personal data. You now want to > upgrade to iPhone SE and find that all your personal data are lost because > there is no way to transfer your data. Very sad. > > The same has happened to me with Squeak. The Squeak programs I have > written over the past 20 years are effectively lost because I can’t port > them to a current version of Squeak. Very sad. > > The essence of object orientation is that objects collaborate to achieve a > goal. I retired 20 years ago and made it my task to create DCI > (Data-Context-Interaction), a programming paradigm that merges the concepts > of class and collaboration. BabyIDE is a non-intrusive Squeak program that > includes a model of DCI as well as tools for programming within the > paradigm. BabyIDE is a kind of Dynabook, a personal computer for experts in > all domains. Its target group could be department managers in business and > industry; they are experts in running their department in collaboration > with other managers. Another target group could be farmers; they are > experts in taking care of their animals. A third target group could be > homeowners; they build expertise in controlling their smart home. > > Squeak is more than a programming language; it is a live universe of > collaborating objects. The shared objects on the web is also a universe of > collaborating objects that Kevin Kelly called a *single, global machine*. > BabyIDE extends the Squeak image into this global machine, making all the > combined objects available for personal programming as illustrated below: > > > > BabyIDE is now running in Squeak 3.10.2, together with a new Squeak > Reverse Engineering tool. I want to port my programs to Squeak 3.5 to > benefit from its improved internet communication facilities. This port has > been pestering me since April, but the overwhelming complexity of 3.5 has > forced me to accept defeat. I can’t avoid speculating about the nature of > Squeak’s current target group. It used to be “children of all ages.” Today, > it neither includes children nor old Smalltalk hands like me (I wrote my > first Smalltalk program in 1978). Stephen Pope, another veteran who also > bemoans what is happening to Squeak, wrote in a blog: > > *“**The most popular systems (Squeak and Pharo) both suffer from > unbelievable image bloat, with many thousands of classes, hundreds of root > classes, class hierarchies with many instance variables in the high-level > (abstract) classes, and too many packages with cute but meaningless (to a > new-comer) names.”* > https://smalltalk.tech.blog/2020/08/10/smalltalks-successor/ > > I couldn’t agree more. A few examples: > > 1. Class Object defines 485 methods. This means that every Squeak > object understands at least 485 messages. Most of them are irrelevant to > the problem at hand, but all of them can be part of unexpected behavior. > > 2. The state of every Morph object is held in its regular instance > variables PLUS any number of undeclared and undocumented variables in its > *extension*, a Dictionary that may include another dictionary inside it. > The Morph class comment: *“MorphExtension Allows extra properties to be > stored without adding a storage burden to all morphs.”* I’m more > concerned about the burden put upon the code reader. > > 3. For me, the final straw was the new filtering phase added to > Squeak’s already complex event handling mechanism. Squeak 3.5 has 208 new > methods with ‘filter’ in their name, but there is no indication as to what > they are for and when to use them. The abstract concepts of event filtering > are documented, but there is no documentation on their reification into > concrete code. The complexity of a basically simple mechanism has reached a > new high far beyond the capabilities of my brain. > > 4. Class MorphicEventDispatcher has 4 methods in 3.10.2 and 16 methods > in 5.3. > > 5. Class *MyMorph>> processEvent: anEvent using: anIgnoredDispatcher* > is a regular event handler in 3.10.2. In 5.3, it is a filter, and its > execution never stops. > > > After 60 years in programming, 42 of them in Smalltalk, and the last 20 in > Squeak, I have reached the end of my patience and reluctantly have to quit > Squeak programming. It is truly a sad day. > > Have fun and Goodbye, > --Trygve > > -- > > *The essence of object orientation is that objects collaborate to achieve > a goal. * > Trygve Reenskaug mailto: trygver at ifi.uio.no <%20trygver at ifi.uio.no> > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway Tel: (+47) 468 58 625 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hikoacdgfinifkep.png Type: image/png Size: 85882 bytes Desc: not available URL: From eliot.miranda at gmail.com Sun Aug 16 04:52:47 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 15 Aug 2020 21:52:47 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: References: Message-ID: <63A94871-C477-4458-B480-84F67F33AD6B@gmail.com> Hi Lawson, > On Aug 15, 2020, at 1:54 PM, LawsonEnglish wrote: > > A followup issue is that simply getting the “External module not found” error the way I do eventually caues either a freeze, or a crash on startup. > > That’s happened with 3 different all-in-one Squeak 5.3’s. > > The debug VM also eventually freezes it seems, when I left it unattended overnight after trying to run that FFI call and getting that error. So far we haven’t figured out where to put a break in the C code to halt just before that error emerges, but just getting that error enough times seems to have its own bad effects on squeak, even if it takes a while to show up. Remember that if you run the vm from a terminal window then when it freezes up you can open another terminal and attach to the process using lldb abd then start exploring, eg using call printAllStacks() and call dumpPrimTraceLog() to find out what state it is in and what was the last external primitive it executed before locking up. You can also simply open a terminal and use pushOutputFile to send output to the new terminal, but that’s a bit involved. > L > >> On Aug 14, 2020, at 9:19 PM, Eliot Miranda wrote: >> >> Hi Lawson, >> >>>> On Aug 14, 2020, at 6:21 PM, LawsonEnglish wrote: >>> >>> I’m not saying it isn’t stable. >> >> I know. I was just saying I don’t think anything has been broken recently, so the issue is not in the FFI per se. >> >>> However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. >> >> There’s a SqueakFFIPlugin dylib (a dylib in all but name) in SqueakFFIPlugin.bundle/Contents/MacOS/SqueakFFIPlugin. That’s what the FFI actually loads. >> >>> I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. >>> >>> SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? >> >> Yes. >> >>> I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. >>> >>> WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. >>> >>> WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? >> >> Yes, and it is extremely tricky. I’ve been using libav and libffmpeg and others. I’ve found one has to examine carefully the output of otool -L and use install_name_tool to change the hard-coded paths of any other non-system Dublin’s a Bykov depends on and make sure one understands and uses @rpath. If your dylib uses any other dylib you’re going to have to do the same exploration. >> >>> >>> I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. >> >> Look at the vm build makefiles for macos; they do this and they can be configured to generate dylibs in a directory, etc. >> >> So first question, what’s the output of >> otool -L mylib >> >> (You can omit all the /System/Library ones) >> >>> L >>> >>>> On Aug 14, 2020, at 6:14 PM, Eliot Miranda wrote: >>>> >>>> Hi Lawson, >>>> >>>>>> On Aug 14, 2020, at 6:04 PM, LawsonEnglish wrote: >>>>> >>>>> I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. >>>>> >>>>> I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. >>>>> >>>>> So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. >>>>> >>>>> Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. >>>> >>>> The FFI tests work out if the biz for me on MacOS 64-bit. The test functions are included in the FFI plugin. I haven’t tried x86/32-bit in a while but I’d be surprised if this was broken. The code is stable. >>>> >>>>> >>>>> >>>>> L >>>>> >>>> >>> >>> >> > > From eliot.miranda at gmail.com Sun Aug 16 04:55:43 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 15 Aug 2020 21:55:43 -0700 Subject: [squeak-dev] May I remove ClassBuilder>format:variable:words:pointers:weak: In-Reply-To: <20200815183619.GA59538@shell.msen.com> References: <20200815183619.GA59538@shell.msen.com> Message-ID: <4D00FE57-63C3-4700-B0CB-E2DFBDF80774@gmail.com> Hi Dave, > On Aug 15, 2020, at 11:36 AM, David T. Lewis wrote: > > ClassBuilder>format:variable:words:pointers:weak: is obsolete and > unreferenced. May I remove it, and also clean up related references > in MethodFinder>>notDangerous? I have no objection. Quite the opposite. > > Asking here so as not to clutter up the inbox. > > Thanks, > Dave > > From LEnglish5 at cox.net Sun Aug 16 07:36:18 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Sun, 16 Aug 2020 00:36:18 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> References: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> Message-ID: <06140EBB-871F-4B72-9996-17E161DC8E80@cox.net> Running otool -L on my dylib: otool -L otool -L libFFITest.dylib libFFITest.dylib: /libFFITest.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) however, running it on the executable int eh SqueakFFIPrims.bundle: otool -L SqueakFFIPrims SqueakFFIPrims: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2) I’m not sure what the difference means. I can sorta remove /libFFITest.dylib but the "(compatibility version 1.0.0, current version 1.0.0)” remains, and I still get the same error whether or not /libFFITest.dylib is present. Can you give me a hint as to what the output from otool -L should look like for a dylib that is useable from within /Resources? L > On Aug 14, 2020, at 9:19 PM, Eliot Miranda wrote: > > Hi Lawson, > >> On Aug 14, 2020, at 6:21 PM, LawsonEnglish wrote: >> >> I’m not saying it isn’t stable. > > I know. I was just saying I don’t think anything has been broken recently, so the issue is not in the FFI per se. > >> However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. > > There’s a SqueakFFIPlugin dylib (a dylib in all but name) in SqueakFFIPlugin.bundle/Contents/MacOS/SqueakFFIPlugin. That’s what the FFI actually loads. > >> I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. >> >> SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? > > Yes. > >> I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. >> >> WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. >> >> WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? > > Yes, and it is extremely tricky. I’ve been using libav and libffmpeg and others. I’ve found one has to examine carefully the output of otool -L and use install_name_tool to change the hard-coded paths of any other non-system Dublin’s a Bykov depends on and make sure one understands and uses @rpath. If your dylib uses any other dylib you’re going to have to do the same exploration. > >> >> I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. > > Look at the vm build makefiles for macos; they do this and they can be configured to generate dylibs in a directory, etc. > > So first question, what’s the output of > otool -L mylib > > (You can omit all the /System/Library ones) > >> L >> >>> On Aug 14, 2020, at 6:14 PM, Eliot Miranda wrote: >>> >>> Hi Lawson, >>> >>>>> On Aug 14, 2020, at 6:04 PM, LawsonEnglish wrote: >>>> >>>> I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. >>>> >>>> I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. >>>> >>>> So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. >>>> >>>> Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. >>> >>> The FFI tests work out if the biz for me on MacOS 64-bit. The test functions are included in the FFI plugin. I haven’t tried x86/32-bit in a while but I’d be surprised if this was broken. The code is stable. >>> >>>> >>>> >>>> L >>>> >>> >> >> > From erik.stel at gmail.com Sun Aug 16 10:25:09 2020 From: erik.stel at gmail.com (Erik Stel) Date: Sun, 16 Aug 2020 05:25:09 -0500 (CDT) Subject: [squeak-dev] Distributed Squeak In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> Message-ID: <1597573509116-0.post@n4.nabble.com> Hi Edgar, Trygve, others, The idea(s) behind CodeParadise should probably [*] lead to a situation in which developing code is based on a number of relative small Smalltalk images. Each image small enough to 'understand'. One image for the application you're developing. One for the development environment. One for the user interface (running inside the browser). Etc. Separating the development environment means I won't be 'seeing' Compiler or Inspector classes when working on my application. IF I do want to add or change a feature of the development environment, I'll open a Browser on that development image and change things there. Being able to change the full environment (consisting of multiple images) should still be possible and effective directly (Smalltalk design principles). Currently I'm mostly busy realising/implementing the tiny image inside the browser (because it is a difficult nut I'd like to crack first). I have chosen Pharo8 as my current development environment, but it should be replaced by my own environment because of the exact bloat Trygve and others refer to. I love Pharo, Squeak(JS) and Cuis. All have their strengths. I'm scheduled for a presentation about this 26th of August on the UK Smalltalk user group (19hrs UK time). Please join if you're interested to see and talk about this. (This part is not well thought out yet, but I'd like to have something like this for CodeParadise:) If you need for example storage you'll probably have another image, somewhat similar to applying a Microservice pattern. These services will not process data (i.e. not your typical REST api), but process objects. These services will at startup not contain the classes/methods of your (business) objects. This also holds for the current tiny image in the browser. It does not contain any code (classes and methods) for views/presenters. All this code is added to the image/service when needed. This allows (but also requires) more independent 'components'. This could lead to specifically compile time configured services or more 'dynamic' services which are 'provisioned' at runtime. So the idea I have is to move away from the traditional single (Smalltalk) image philosophy. @Trygve, thanks for all your nice work. Hope you're doing well. My description above is not the same as what you describe, but it feels like it could have a similar end result (if I understand you correctly). Still so much to do...so I won't be offering a solution anytime soon. Wish I could... [*] Things are still in early development and I haven't thought out all the details yet. Some things might not work when theory meets practice ;-). Cheers, Erik -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From edgardec2005 at gmail.com Sun Aug 16 11:08:39 2020 From: edgardec2005 at gmail.com (Edgar J. De Cleene) Date: Sun, 16 Aug 2020 08:08:39 -0300 Subject: [squeak-dev] Trying to help to bring BabySRE to modern Squeak Message-ID: I digging in old experiments So I found a 7179-basic.226publ.image and some .mcz we made with Hannes Hirzel long time ago Bring all BabySRE to modern Squeak take longer to me , so I share for young people my founds. Problems come of format changes in .image and also in missing dependencies Here you have some BabySRE in old 4.5 running in old iMac 2009 with John VM. I continue this line of work trying to found missing pieces. Edgar @morplenauta -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: world.jpeg URL: From vanessa at codefrau.net Mon Aug 17 01:56:56 2020 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Sun, 16 Aug 2020 18:56:56 -0700 Subject: [squeak-dev] Distributed Squeak In-Reply-To: <1597573509116-0.post@n4.nabble.com> References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> <1597573509116-0.post@n4.nabble.com> Message-ID: On Sun, Aug 16, 2020 at 3:25 AM Erik Stel wrote: > > I'm scheduled for a presentation about this 26th of August on the UK > Smalltalk user group (19hrs UK time). Please join if you're interested to > see and talk about this. > Will this be virtual or physical? The meetup page suggests it's in London: https://www.meetup.com/UKSTUG/events/cbklbrybclbjc/ Vanessa -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.stel at gmail.com Mon Aug 17 05:43:11 2020 From: erik.stel at gmail.com (Erik Stel) Date: Mon, 17 Aug 2020 00:43:11 -0500 (CDT) Subject: [squeak-dev] Distributed Squeak In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> <1597573509116-0.post@n4.nabble.com> Message-ID: <1597642991587-0.post@n4.nabble.com> Hi Vanessa, It will be an online meetup. Hope to see you there. Cheers, Erik -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From marcel.taeumel at hpi.de Mon Aug 17 08:34:06 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Mon, 17 Aug 2020 10:34:06 +0200 Subject: [squeak-dev] May I remove ClassBuilder>format:variable:words:pointers:weak: In-Reply-To: <4D00FE57-63C3-4700-B0CB-E2DFBDF80774@gmail.com> References: <20200815183619.GA59538@shell.msen.com> <4D00FE57-63C3-4700-B0CB-E2DFBDF80774@gmail.com> Message-ID: Hi Dave, would it help users to keep it around as deprecated? Could there be a fall-back implementation to non-deprecated code? Best, Marcel Am 16.08.2020 06:55:56 schrieb Eliot Miranda : Hi Dave, > On Aug 15, 2020, at 11:36 AM, David T. Lewis wrote: > > ClassBuilder>format:variable:words:pointers:weak: is obsolete and > unreferenced. May I remove it, and also clean up related references > in MethodFinder>>notDangerous? I have no objection. Quite the opposite. > > Asking here so as not to clutter up the inbox. > > Thanks, > Dave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Mon Aug 17 10:54:11 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 17 Aug 2020 10:54:11 0000 Subject: [squeak-dev] The Trunk: System-mt.1169.mcz Message-ID: Marcel Taeumel uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-mt.1169.mcz ==================== Summary ==================== Name: System-mt.1169 Author: mt Time: 17 August 2020, 12:54:05.667289 pm UUID: dfd26c6f-79f7-f146-95c1-78751d5f8f13 Ancestors: System-eem.1168 Clarify implementation of method timestamps. Note that #hhmm24 cannot be used here, because it has no colon separator. =============== Diff against System-eem.1168 =============== Item was changed: ----- Method: Utilities class>>changeStamp (in category 'identification') ----- changeStamp "Answer a string to be pasted into source code to mark who changed it and when." ^ self authorInitials , ' ' , Date today mmddyyyy, ' ', + (String streamContents: [:s | Time now print24: true showSeconds: false on: s])! - ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 5)! From Patrick.Rein at hpi.de Mon Aug 17 11:58:39 2020 From: Patrick.Rein at hpi.de (Rein, Patrick) Date: Mon, 17 Aug 2020 11:58:39 +0000 Subject: [squeak-dev] Parser Pragma Issue and Fix Message-ID: <1f4f306849d24b75996f9a9ae8a8372e@hpi.de> Hi everyone, while working on a parser framework I recently discovered an issue when parsing the following method: someTestMethod '<' first This method can not be parsed by the current Squeak parser, as it expects a closing angle bracket after the message send. The parser misinterprets the bracket in the string as the beginning of a pragma. The fault is in the Parser class which did not respect the type of the token to be parsed. The attached changeset is a proposed fix for the fault. It boils down to checking for the #binary token type in the the responsible parser method: Parser>>#pragmaSequence "Parse a sequence of method pragmas." [ (hereType == #binary and: [self matchToken: #<]) ifFalse: [ ^ self ]. self pragmaStatement. (self matchToken: #>) ifFalse: [ ^ self expected: '>' ] ] repeat As this is somewhat of a fundamental change, I wanted to bring this up for discussion before merging it. Thanks and best wishes, Patrick -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ParserPragmaFix.1.cs URL: From lewis at mail.msen.com Mon Aug 17 14:57:06 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 17 Aug 2020 10:57:06 -0400 Subject: [squeak-dev] May I remove ClassBuilder>format:variable:words:pointers:weak: In-Reply-To: References: <20200815183619.GA59538@shell.msen.com> <4D00FE57-63C3-4700-B0CB-E2DFBDF80774@gmail.com> Message-ID: <20200817145706.GA7655@shell.msen.com> Hi Marcel, On Mon, Aug 17, 2020 at 10:34:06AM +0200, Marcel Taeumel wrote: > Hi Dave, > > would it help users to keep it around as deprecated? Could there be a fall-back implementation to non-deprecated code? > Yes we could move it to 60Deprecated. Actually we could have deprecated it several years ago. But just deleting it and cleaning up the references in MethodFinder seems safe enough at this point. Basically ClassBuilder>format:variable:words:pointers:weak: has been serving as the fallback method for its replacement method ClassBuilder>format:variable:bitsUnitSize:pointers:weak: which has been in use for the last several years. The difference is that the new method allows specification of 64-bit and 16-bit data sizes, not just 32-bit and 8-bit as before. I am fairly sure that the method is intended only for private use by the system itself (including Montecello). I checked Magma, and there are no references there either. This is not urgent, I will wait a couple of days before doing anything. Dave > Best, > Marcel > Am 16.08.2020 06:55:56 schrieb Eliot Miranda : > Hi Dave, > > > On Aug 15, 2020, at 11:36 AM, David T. Lewis wrote: > > > > ???ClassBuilder>format:variable:words:pointers:weak: is obsolete and > > unreferenced. May I remove it, and also clean up related references > > in MethodFinder>>notDangerous? > > I have no objection. Quite the opposite. > > > > > Asking here so as not to clutter up the inbox. > > > > Thanks, > > Dave > > > > > > From jrmaffeo at gmail.com Mon Aug 17 20:28:54 2020 From: jrmaffeo at gmail.com (John-Reed Maffeo) Date: Mon, 17 Aug 2020 13:28:54 -0700 Subject: [squeak-dev] Trying to help to bring BabySRE to modern Squeak In-Reply-To: References: Message-ID: Edgar, Thank you for working to bring Baby SRE up to a more current Squeak release. This is a kind gift to the community. -jrm On Sun, Aug 16, 2020 at 4:08 AM Edgar J. De Cleene wrote: > I digging in old experiments > > So I found a 7179-basic.226publ.image and some .mcz we made with Hannes > Hirzel long time ago > > Bring all BabySRE to modern Squeak take longer to me , so I share for young > people my founds. > > Problems come of format changes in .image and also in missing dependencies > > Here you have some BabySRE in old 4.5 running in old iMac 2009 with John > VM. > > I continue this line of work trying to found missing pieces. > > > Edgar > @morplenauta > > > -- John-Reed Maffeo -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.withers at pm.me Mon Aug 17 20:54:16 2020 From: robert.withers at pm.me (Robert Withers) Date: Mon, 17 Aug 2020 20:54:16 +0000 Subject: [squeak-dev] a yCombinator thread on TruffleSqueak Message-ID: I saw this thread and so I would share. https://news.ycombinator.com/item?id=24180701 K, r From asqueaker at gmail.com Tue Aug 18 04:38:13 2020 From: asqueaker at gmail.com (Chris Muller) Date: Mon, 17 Aug 2020 23:38:13 -0500 Subject: [squeak-dev] May I remove ClassBuilder>format:variable:words:pointers:weak: In-Reply-To: <20200817145706.GA7655@shell.msen.com> References: <20200815183619.GA59538@shell.msen.com> <4D00FE57-63C3-4700-B0CB-E2DFBDF80774@gmail.com> <20200817145706.GA7655@shell.msen.com> Message-ID: > > I checked Magma, and there > are no references there either. > Aww, thanks Dave! :) Sincerely, I was just getting ready to check myself when I saw this. Magma uses ClassBuilder in a couple of places, but this selector didn't ring a bell. - Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at fniephaus.com Tue Aug 18 09:01:13 2020 From: lists at fniephaus.com (Fabio Niephaus) Date: Tue, 18 Aug 2020 11:01:13 +0200 Subject: [squeak-dev] a yCombinator thread on TruffleSqueak In-Reply-To: References: Message-ID: On Mon, Aug 17, 2020 at 10:54 PM Robert Withers via Squeak-dev wrote: > > I saw this thread and so I would share. > > https://news.ycombinator.com/item?id=24180701 > Thanks for sharing the link here, it was cool to see this on their front page. Please feel free to get in touch if you have any questions. Cheers, Fabio > K, r > > > From giovanni at corriga.net Tue Aug 18 10:15:18 2020 From: giovanni at corriga.net (Giovanni Corriga) Date: Tue, 18 Aug 2020 11:15:18 +0100 Subject: [squeak-dev] UK Smalltalk User Group meeting - Wednesday, August 26th Message-ID: The next meeting of the UK Smalltalk User Group will be on Wednesday, August 26th. In this meeting, Erik Stel will present his current project - CodeParadise. CodeParadise is a cloud based platform (to be) to learn to program using Object Oriented principles within a Smalltalk environment. CodeParadise is still in very early development, but some of its results have seen interest from the community. Therefore a presentation will provide insight in the design, current status, and possibilities of the results so far. The discussion afterwards can be used for both in-depth technical topics as well as the more philosophical topics about programming (as warmth and/or beer consumption will guide us). Given the current COVID-19 restrictions, this will be an online meeting from home. If you'd like to join us, please sign up in advance on the meeting's Meetup page https://www.meetup.com/UKSTUG/events/cbklbrybclbjc/ to receive the meeting details. Don’t forget to bring your laptop and drinks! Cheers, Giovanni -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Tue Aug 18 15:06:19 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue, 18 Aug 2020 08:06:19 -0700 Subject: [squeak-dev] Parser Pragma Issue and Fix In-Reply-To: <1f4f306849d24b75996f9a9ae8a8372e@hpi.de> References: <1f4f306849d24b75996f9a9ae8a8372e@hpi.de> Message-ID: <26D4BB02-A70F-4E7B-A8A3-E51E18E7A384@gmail.com> Hi Patrick, please push to trunk ASAP. What a terrible blunder on my part!! _,,,^..^,,,_ (phone) > On Aug 17, 2020, at 4:58 AM, Rein, Patrick wrote: > > Hi everyone, > > while working on a parser framework I recently discovered an issue when parsing the following method: > > someTestMethod > '<' first > > This method can not be parsed by the current Squeak parser, as it expects a closing angle bracket after the message send. The parser misinterprets the bracket in the string as the beginning of a pragma. The fault is in the Parser class which did not respect the type of the token to be parsed. The attached changeset is a proposed fix for the fault. It boils down to checking for the #binary token type in the the responsible parser method: > > Parser>>#pragmaSequence > "Parse a sequence of method pragmas." > > [ (hereType == #binary and: [self matchToken: #<]) > ifFalse: [ ^ self ]. > self pragmaStatement. > (self matchToken: #>) > ifFalse: [ ^ self expected: '>' ] ] repeat > > As this is somewhat of a fundamental change, I wanted to bring this up for discussion before merging it. > > Thanks and best wishes, > Patrick > > From eliot.miranda at gmail.com Tue Aug 18 15:13:53 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Tue, 18 Aug 2020 08:13:53 -0700 Subject: [squeak-dev] The Trunk: System-mt.1169.mcz In-Reply-To: References: Message-ID: <6AC7265F-C691-451A-9DBC-7F8201A1C71B@gmail.com> Hi Marcel, hi all, this reminds me I think we also need something that answers an actual TimeStamp or DateAndTime instance for a CompiledMethod. Unfortunately timeStamp is already in use as the selector for a method’s change stamp string. In an ideal world CompiledMethod>>#timeStamp would be renamed to CompiledMethod>>#changeStamp and CompiledMethod>>#timeStamp would answer a DateAndTime of either the method’s changeStamp time or the epoch, if it had none. _,,,^..^,,,_ (phone) > On Aug 17, 2020, at 3:54 AM, commits at source.squeak.org wrote: > > Marcel Taeumel uploaded a new version of System to project The Trunk: > http://source.squeak.org/trunk/System-mt.1169.mcz > > ==================== Summary ==================== > > Name: System-mt.1169 > Author: mt > Time: 17 August 2020, 12:54:05.667289 pm > UUID: dfd26c6f-79f7-f146-95c1-78751d5f8f13 > Ancestors: System-eem.1168 > > Clarify implementation of method timestamps. > > Note that #hhmm24 cannot be used here, because it has no colon separator. > > =============== Diff against System-eem.1168 =============== > > Item was changed: > ----- Method: Utilities class>>changeStamp (in category 'identification') ----- > changeStamp > "Answer a string to be pasted into source code to mark who changed it and when." > ^ self authorInitials , ' ' , Date today mmddyyyy, ' ', > + (String streamContents: [:s | Time now print24: true showSeconds: false on: s])! > - ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 5)! > > From vanessa at codefrau.net Tue Aug 18 17:19:15 2020 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Tue, 18 Aug 2020 10:19:15 -0700 Subject: [squeak-dev] UK Smalltalk User Group meeting - Wednesday, August 26th In-Reply-To: References: Message-ID: This should be interesting - Erik is using SqueakJS for the in-browser component. - Vanessa - On Tue, Aug 18, 2020 at 3:15 AM Giovanni Corriga wrote: > The next meeting of the UK Smalltalk User Group will be on Wednesday, > August 26th. > In this meeting, Erik Stel will present his current project - CodeParadise. > > CodeParadise is a cloud based platform (to be) to learn to program using > Object Oriented principles within a Smalltalk environment. > CodeParadise is still in very early development, but some of its results > have seen interest from the community. Therefore a presentation will > provide insight in the design, current status, and possibilities of the > results so far. > The discussion afterwards can be used for both in-depth technical topics > as well as the more philosophical topics about programming (as warmth > and/or beer consumption will guide us). > > Given the current COVID-19 restrictions, this will be an online meeting > from home. > If you'd like to join us, please sign up in advance on the meeting's > Meetup page https://www.meetup.com/UKSTUG/events/cbklbrybclbjc/ to > receive the meeting details. > > Don’t forget to bring your laptop and drinks! > > Cheers, > > Giovanni > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leves at caesar.elte.hu Tue Aug 18 19:49:38 2020 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Tue, 18 Aug 2020 21:49:38 +0200 (CEST) Subject: [squeak-dev] Parser Pragma Issue and Fix In-Reply-To: <1f4f306849d24b75996f9a9ae8a8372e@hpi.de> References: <1f4f306849d24b75996f9a9ae8a8372e@hpi.de> Message-ID: Hi Patrick, On Mon, 17 Aug 2020, Rein, Patrick wrote: > Hi everyone, > > while working on a parser framework I recently discovered an issue when parsing the following method: > > someTestMethod > '<' first > > This method can not be parsed by the current Squeak parser, as it expects a closing angle bracket after the message send. The parser misinterprets the bracket in the string as the beginning of a pragma. The fault is in the Parser class which did not respect the type of the token to be parsed. The attached changeset is a proposed fix for the fault. It boils down to checking for the #binary token type in the the responsible parser method: > > Parser>>#pragmaSequence > "Parse a sequence of method pragmas." > > [ (hereType == #binary and: [self matchToken: #<]) > ifFalse: [ ^ self ]. > self pragmaStatement. > (self matchToken: #>) > ifFalse: [ ^ self expected: '>' ] ] repeat > > As this is somewhat of a fundamental change, I wanted to bring this up for discussion before merging it. The issue exists the other way around with the closing bracket as well. After applying your fix compile: someTestMethod ' ^1 The same fix seems to work there too: ... (hereType == #binary and: [self matchToken: #>]) ifFalse: [ ^ self expected: '>' ] ] repeat Levente > > Thanks and best wishes, > Patrick From craig at blackpagedigital.com Wed Aug 19 05:54:47 2020 From: craig at blackpagedigital.com (Craig Latta) Date: Tue, 18 Aug 2020 22:54:47 -0700 Subject: [squeak-dev] Distributed Squeak In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> Message-ID: Hi-- Karl writes: > Craig Latta has been developing similar stuff for a while Tim responds: > It's about 20 years now, IIRC. Since 2002... At least Squeak will turn 25 before this hits 20. :) -C -- Craig Latta Black Page Digital Berkeley, California blackpagedigital.com From craig at blackpagedigital.com Wed Aug 19 06:11:05 2020 From: craig at blackpagedigital.com (Craig Latta) Date: Tue, 18 Aug 2020 23:11:05 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: References: Message-ID: Hi Lawson-- > I let Craig Latta watch me, via screen sharing on skype, set up the > whole thing from scratch, and his response was to start to coach me in > how to create and use the VM with a c-debugger. No, catching your error with the C debugger was my first suggestion after hearing FFI wasn't working for you, before I saw anything. Helping you set up the VM build and debugging environment was the reason for the screen-sharing session. > So I don’t think I’m doing anything obviously wrong or at least Craig > didn’t catch it while he watched. I wasn't trying to catch anything. I was helping you set up the tools for finding the wrong thing yourself. -C -- Craig Latta Black Page Digital Berkeley, California blackpagedigital.com From Das.Linux at gmx.de Wed Aug 19 07:31:05 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Wed, 19 Aug 2020 09:31:05 +0200 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: <06140EBB-871F-4B72-9996-17E161DC8E80@cox.net> References: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> <06140EBB-871F-4B72-9996-17E161DC8E80@cox.net> Message-ID: Hi > On 16.08.2020, at 09:36, LawsonEnglish wrote: > > Running otool -L on my dylib: > > otool -L otool -L libFFITest.dylib > libFFITest.dylib: > /libFFITest.dylib (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) > > however, running it on the executable int eh SqueakFFIPrims.bundle: > > otool -L SqueakFFIPrims > SqueakFFIPrims: > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2) > > > I’m not sure what the difference means. I can sorta remove /libFFITest.dylib but the "(compatibility version 1.0.0, current version 1.0.0)” remains, and I still get the same error whether or not /libFFITest.dylib is present. > > there's a stark difference, sadly. The Plugins, which are bundles on macOS, are _not_ simply dynamic libs: [Squeak.app/Contents/Resources]$ otool -L CameraPlugin.bundle/Contents/MacOS/CameraPlugin CameraPlugin.bundle/Contents/MacOS/CameraPlugin: /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation (compatibility version 1.0.0, current version 2.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1450.15.0) /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1129.5.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1450.15.0) /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) [Squeak.app/Contents/Resources]$ file CameraPlugin.bundle/Contents/MacOS/CameraPlugin CameraPlugin.bundle/Contents/MacOS/CameraPlugin: Mach-O 64-bit bundle x86_64 Dynamic libs look differently: [~]$ otool -L /usr/lib/libbz2.dylib /usr/lib/libbz2.dylib: /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2) [~]$ file /usr/lib/libbz2.dylib /usr/lib/libbz2.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [i386:Mach-O dynamically linked shared library i386] /usr/lib/libbz2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 /usr/lib/libbz2.dylib (for architecture i386): Mach-O dynamically linked shared library i386 =-=-= I would suggest you first try to call a known function in a known library. For example: const char* BZ2_bzlibVersion(void); from libbzip2. =-=-= Other than that, I can't help without some artifact to look at, sorry :/ Best regards -Tobias > > Can you give me a hint as to what the output from otool -L should look like for a dylib that is useable from within /Resources? > > L > > >> On Aug 14, 2020, at 9:19 PM, Eliot Miranda wrote: >> >> Hi Lawson, >> >>> On Aug 14, 2020, at 6:21 PM, LawsonEnglish wrote: >>> >>> I’m not saying it isn’t stable. >> >> I know. I was just saying I don’t think anything has been broken recently, so the issue is not in the FFI per se. >> >>> However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. >> >> There’s a SqueakFFIPlugin dylib (a dylib in all but name) in SqueakFFIPlugin.bundle/Contents/MacOS/SqueakFFIPlugin. That’s what the FFI actually loads. >> >>> I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. >>> >>> SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? >> >> Yes. >> >>> I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. >>> >>> WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. >>> >>> WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? >> >> Yes, and it is extremely tricky. I’ve been using libav and libffmpeg and others. I’ve found one has to examine carefully the output of otool -L and use install_name_tool to change the hard-coded paths of any other non-system Dublin’s a Bykov depends on and make sure one understands and uses @rpath. If your dylib uses any other dylib you’re going to have to do the same exploration. >> >>> >>> I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. >> >> Look at the vm build makefiles for macos; they do this and they can be configured to generate dylibs in a directory, etc. >> >> So first question, what’s the output of >> otool -L mylib >> >> (You can omit all the /System/Library ones) >> >>> L >>> >>>> On Aug 14, 2020, at 6:14 PM, Eliot Miranda wrote: >>>> >>>> Hi Lawson, >>>> >>>>> >>>>> I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. >>>>> >>>>> I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. >>>>> >>>>> So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. >>>>> >>>>> Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. >>>> >>>> The FFI tests work out if the biz for me on MacOS 64-bit. The test functions are included in the FFI plugin. I haven’t tried x86/32-bit in a while but I’d be surprised if this was broken. The code is stable. >>>> >>>>> >>>>> >>>>> L >>>>> >>>> >>> >>> >> > > From Christoph.Thiede at student.hpi.uni-potsdam.de Wed Aug 19 11:07:24 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Wed, 19 Aug 2020 11:07:24 +0000 Subject: [squeak-dev] error on process termination In-Reply-To: References: , Message-ID: <7a078b206c314c0abf726dcdfedd2760@student.hpi.uni-potsdam.de> Hi Robert, without knowing details about your error, can you eliminate the infinite loop by applying any of the proposed solutions from http://forum.world.st/I-broke-the-debugger-td5110752.html#a5110814? Squeak - Dev - I broke the debugger? forum.world.st I broke the debugger?. Weird thing her. I was trying out my old Plumbing example, mostly just as a way to improve the swiki page. Using a 19292 update 5.3 image on Mac. Found a recursion related bug in... Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Robert Withers via Squeak-dev Gesendet: Samstag, 25. Juli 2020 14:22:47 An: Squeak-dev Betreff: Re: [squeak-dev] error on process termination To give you more context, I am looking into gaurding the Vat's eventualProcess to restart when curtailed. This method is the main processing event loop. Below that is the #restartEventLoop method. PriorityVat>>#processSends [ [Processor yield. self nextPriorityMsg ifNotNil: [:msg | msg value]. normalQ notNil ] ifCurtailed: [self restartEventLoop]] whileTrue PriorityVat>>#restartEventLoop | currentEventLoop | (Processor activeProcess == eventualProcess) ifTrue: [ eventualProcess ifNotNil: [:ea | currentEventLoop := ea]. eventualProcess := nil. eventualProcess := EventualProcess newOnVat: self. eventualProcess resumeAsProcess. currentEventLoop ifNotNil: [:ea | ea terminate ]]. The termination is where the #stepToCallee error occurs. K, r On 7/25/20 8:13 AM, Robert Withers wrote: Hi y'all, I am getting an error when terminating my process and it loops infinitely stacking this error recursively. nil doesNotUnderstand: stepToCallee This is called from Context>>#runUntilErrorOrReturnFrom: aSender after this method has tried to get the topContext. Somehow topContext is nil, and I am guessing that returns from one of the context pops, in the following code from #runUntilErrorOrReturnFrom:. "Control resumes here once above ensure block or exception handler is executed" ^ error ifNil: [ "No error was raised, remove ensure context by stepping until popped" [ctxt isDead] whileFalse: [topContext := topContext stepToCallee]. {topContext. nil} Have I setup the process incorrectly to receive this error or is something else the issue? Appreciated. Kindly, rabbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Wed Aug 19 16:38:58 2020 From: tim at rowledge.org (tim Rowledge) Date: Wed, 19 Aug 2020 09:38:58 -0700 Subject: [squeak-dev] Distributed Squeak In-Reply-To: References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> Message-ID: <5DC3DFD9-5B86-4104-BFD7-DB7608BC13C8@rowledge.org> > On 2020-08-18, at 10:54 PM, Craig Latta wrote: > > > Hi-- > > Karl writes: > >> Craig Latta has been developing similar stuff for a while > > Tim responds: > >> It's about 20 years now, IIRC. > > Since 2002... At least Squeak will turn 25 before this hits 20. :) Ah yes. A couple of years before we moved up north. I remember discussions about it at the place in Portola Valley... and I remember racing a Porsche 911 around the 280 on my way to visit. :-) tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim "Bother," said Pooh, as Satan pointed out the fine print... From Christoph.Thiede at student.hpi.uni-potsdam.de Wed Aug 19 18:15:09 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Wed, 19 Aug 2020 18:15:09 +0000 Subject: [squeak-dev] What is primitiveDropRequestFileHandle and do we really need it? Message-ID: <4527e4f1d7694dbd8fb9a736096e70a2@student.hpi.uni-potsdam.de> Hi all, as some of you already might have noticed [1, 2], I am currently working at a more powerful Drag and Drop (DnD) handling at the VM level of Squeak, heavily inspired by Marcel's ideas. While studying the existing source code, I was wondering what is the actual purpose of primitiveDropRequestFileHandle compared to primitiveDropRequestFileName which both are called by StandardFileStream >> #requestDropStream:. I had a very short look at all the different DropPlugin implementations and in a nutshell, dropRequestFileHandle appears to call dropRequestFileName and then sqFileOpen() that path using the FilePlugin. Compared to this, the regular primitiveFileOpen from the FilePlugin which is called by StandardFileStream >> #open:forWrite: leads to fileOpenNamesizewritesecure() which first performs some ominous security checks (basically whether the file path is valid and the file is writable if needed) and then, again, calls sqFileOpen(). So at the end of the day, both primitives appear to call the same logic. So please allow me my naive question: Does anyone remember or imagine any good reason why we have an additional primitive for this purpose? My overall guess (from what I have learned so far about the VM side) would have been that you should be as frugal as possible when it comes to introducing a primitive, because developing, debugging, and exploring VM code is so much less simple and intuitive than Smalltalk code. For this reason, I would not expect to find any redundant "convenience primitives" in the OSVM interface. I have two hypothetical explanations so far which however both I do not find satisfying: * Optimization: Could there have been some ancient times where it might have been wise to save a redundant call to the SecurityPlugin after you have got a trusted file path from the host system? * Buggy SecurityPlugin: Could there be any situation in which the SecurityPlugin would refuse a special file path returned by the DropPlugin though it can be opened by sqFileOpen()? But I cannot experience such a situation. Tl;dr: What is the reason for the existence of primitiveDropRequestFileHandle and should it still be used? Why not simply nuke it and always use primitiveDropRequestFileName + primitiveFileOpen? Looking forward to your suggestions! Best, Christoph [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/514 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirtai+st at gmail.com Wed Aug 19 18:22:18 2020 From: kirtai+st at gmail.com (Douglas Brebner) Date: Wed, 19 Aug 2020 19:22:18 +0100 Subject: [squeak-dev] Distributed Squeak In-Reply-To: <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> Message-ID: On 15/08/2020 08:56, Trygve Reenskaug wrote: > Just an idea while a car is waiting to take me on a vacation. > > Imagine: > > 1. You have a computer with many independently running images. > 2. A super fast facility pass messages between the images, > 3. Selected services in the release image are move out and deployed > as server objects in another image. > 4. Every image appears as a server offering RESTful interfaces to > other images. > 5. Selected packages in any repository can be downloaded, compiled, > instantiated, and deployed in an image as server objects. > 6. The different images can even run in different computers and use > different VMs. > 7. There are now two dimensions to the reuse of functionality: a) > download and compile a package. b In some image, install a package > and deploy it as a server object. > 8. And presto: The original image is now small and manageable while > the whole system can grow without increasing the complexity of the > release image. > > In haste. This is just an idea. It's full of holes and need a lot of > work done to it before it can be usable.. It's a disruptive idea, so > please give it some consideration This is before you shoot it down > --Trygve > Sort of like using Images as Actors? -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Wed Aug 19 18:41:15 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 19 Aug 2020 18:41:15 0000 Subject: [squeak-dev] The Trunk: Kernel-dtl.1336.mcz Message-ID: David T. Lewis uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-dtl.1336.mcz ==================== Summary ==================== Name: Kernel-dtl.1336 Author: dtl Time: 19 August 2020, 2:41:12.037984 pm UUID: 1a934e94-87e5-4af3-b6c7-0d1caa848121 Ancestors: Kernel-eem.1335 Remove obsolete Classbuilder>>format:variable:words:pointers:weak: which was replaced by Classbuilder>>format:variable:bitsUnitSize:pointers:weak: a few years ago. This is effectively a private method and does not require deprecation. =============== Diff against Kernel-eem.1335 =============== Item was removed: - ----- Method: ClassBuilder>>format:variable:words:pointers:weak: (in category 'class format') ----- - format: nInstVars variable: isVar words: is32BitWords pointers: isPointers weak: isWeak - "Compute the format for the given instance specfication. - Above Cog Spur the class format is - <5 bits inst spec><16 bits inst size> - where the 5-bit inst spec is - 0 = 0 sized objects (UndefinedObject True False et al) - 1 = non-indexable objects with inst vars (Point et al) - 2 = indexable objects with no inst vars (Array et al) - 3 = indexable objects with inst vars (Context BlockClosure AdditionalMethodState et al) - 4 = weak indexable objects with inst vars (WeakArray et al) - 5 = weak non-indexable objects with inst vars (ephemerons) (Ephemeron) - 6 = unused - 7 = immediates (SmallInteger, Character) - 8 = unused - 9 = reserved for 64-bit indexable - 10-11 = 32-bit indexable (Bitmap) - 12-15 = 16-bit indexable - 16-23 = 8-bit indexable - 24-31 = compiled methods (CompiledMethod)" - | instSpec | - instSpec := isWeak - ifTrue: - [isVar - ifTrue: [4] - ifFalse: [5]] - ifFalse: - [isPointers - ifTrue: - [isVar - ifTrue: [nInstVars > 0 ifTrue: [3] ifFalse: [2]] - ifFalse: [nInstVars > 0 ifTrue: [1] ifFalse: [0]]] - ifFalse: - [isVar - ifTrue: [is32BitWords ifTrue: [10] ifFalse: [16]] - ifFalse: [7]]]. - ^(instSpec bitShift: 16) + nInstVars! From Christoph.Thiede at student.hpi.uni-potsdam.de Wed Aug 19 18:43:00 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Wed, 19 Aug 2020 18:43:00 +0000 Subject: [squeak-dev] The Trunk: System-mt.1169.mcz In-Reply-To: <6AC7265F-C691-451A-9DBC-7F8201A1C71B@gmail.com> References: , <6AC7265F-C691-451A-9DBC-7F8201A1C71B@gmail.com> Message-ID: > this reminds me I think we also need something that answers an actual TimeStamp or DateAndTime instance for a CompiledMethod. +1 for doing this. The current timeStamp string might be necessary from an implementation view, but from an object model view it is a shame that such an important object commits such primitive obsession. It would be so nice if you could do something like CompiledMethod allInstances sorted: #dateTimeStamp asSortFunction Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Eliot Miranda Gesendet: Dienstag, 18. August 2020 17:13:53 An: squeak-dev at lists.squeakfoundation.org Betreff: Re: [squeak-dev] The Trunk: System-mt.1169.mcz Hi Marcel, hi all, this reminds me I think we also need something that answers an actual TimeStamp or DateAndTime instance for a CompiledMethod. Unfortunately timeStamp is already in use as the selector for a method’s change stamp string. In an ideal world CompiledMethod>>#timeStamp would be renamed to CompiledMethod>>#changeStamp and CompiledMethod>>#timeStamp would answer a DateAndTime of either the method’s changeStamp time or the epoch, if it had none. _,,,^..^,,,_ (phone) > On Aug 17, 2020, at 3:54 AM, commits at source.squeak.org wrote: > > Marcel Taeumel uploaded a new version of System to project The Trunk: > http://source.squeak.org/trunk/System-mt.1169.mcz > > ==================== Summary ==================== > > Name: System-mt.1169 > Author: mt > Time: 17 August 2020, 12:54:05.667289 pm > UUID: dfd26c6f-79f7-f146-95c1-78751d5f8f13 > Ancestors: System-eem.1168 > > Clarify implementation of method timestamps. > > Note that #hhmm24 cannot be used here, because it has no colon separator. > > =============== Diff against System-eem.1168 =============== > > Item was changed: > ----- Method: Utilities class>>changeStamp (in category 'identification') ----- > changeStamp > "Answer a string to be pasted into source code to mark who changed it and when." > ^ self authorInitials , ' ' , Date today mmddyyyy, ' ', > + (String streamContents: [:s | Time now print24: true showSeconds: false on: s])! > - ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 5)! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Wed Aug 19 19:41:53 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Wed, 19 Aug 2020 15:41:53 -0400 Subject: [squeak-dev] Is it dangerous to ignore Dangerous? Message-ID: <20200819194153.GA10737@shell.msen.com> Following the removal of Classbuilder>>format:variable:words:pointers:weak: I had planned to remove a reference to that method (and one or two others) in MethodFinder>>noteDangerous. But to my surprise, I see that the set of Dangerous methods in MethodFinder is completely unused (except by a method that is itself unused). How is this even possible? I had assumed that the Dangerous methods were important to the fundamental functioning of MethodFinder, which explores the system looking for methods that produce results matching some example pattern. How could this possibly be working if we do not pay attention to the set of methods that are too dangerous to be invoked by the method finder? This is not a new situation, I looked at a Squeak 3.6 image and see the same thing. Dave From karlramberg at gmail.com Wed Aug 19 20:21:51 2020 From: karlramberg at gmail.com (karl ramberg) Date: Wed, 19 Aug 2020 22:21:51 +0200 Subject: [squeak-dev] Is it dangerous to ignore Dangerous? In-Reply-To: <20200819194153.GA10737@shell.msen.com> References: <20200819194153.GA10737@shell.msen.com> Message-ID: Same in Squeak 2.8. Dangerous is nil and not accessed. Best, Karl On Wed, Aug 19, 2020 at 9:41 PM David T. Lewis wrote: > Following the removal of Classbuilder>>format:variable:words:pointers:weak: > I had planned to remove a reference to that method (and one or two others) > in MethodFinder>>noteDangerous. But to my surprise, I see that the set of > Dangerous methods in MethodFinder is completely unused (except by a method > that is itself unused). > > How is this even possible? I had assumed that the Dangerous methods were > important to the fundamental functioning of MethodFinder, which explores > the system looking for methods that produce results matching some example > pattern. How could this possibly be working if we do not pay attention to > the set of methods that are too dangerous to be invoked by the method > finder? > > This is not a new situation, I looked at a Squeak 3.6 image and see the > same thing. > > Dave > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa at codefrau.net Wed Aug 19 21:29:51 2020 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Wed, 19 Aug 2020 14:29:51 -0700 Subject: [squeak-dev] Is it dangerous to ignore Dangerous? In-Reply-To: References: <20200819194153.GA10737@shell.msen.com> Message-ID: Not sure why the methods in noteDangerous are not used. We could ask Ted, who wrote it initially. CC'ing. It still works because MethodFinder only tries methods understood by the objects you give as an example. So as long as you don't try it on "dangerous" classes it's going to be fine. - Vanessa - On Wed, Aug 19, 2020 at 1:22 PM karl ramberg wrote: > Same in Squeak 2.8. > Dangerous is nil and not accessed. > > Best, > > Karl > > On Wed, Aug 19, 2020 at 9:41 PM David T. Lewis > wrote: > >> Following the removal of >> Classbuilder>>format:variable:words:pointers:weak: >> I had planned to remove a reference to that method (and one or two others) >> in MethodFinder>>noteDangerous. But to my surprise, I see that the set of >> Dangerous methods in MethodFinder is completely unused (except by a method >> that is itself unused). >> >> How is this even possible? I had assumed that the Dangerous methods were >> important to the fundamental functioning of MethodFinder, which explores >> the system looking for methods that produce results matching some example >> pattern. How could this possibly be working if we do not pay attention to >> the set of methods that are too dangerous to be invoked by the method >> finder? >> >> This is not a new situation, I looked at a Squeak 3.6 image and see the >> same thing. >> >> Dave >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa at codefrau.net Wed Aug 19 21:42:52 2020 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Wed, 19 Aug 2020 14:42:52 -0700 Subject: [squeak-dev] What is primitiveDropRequestFileHandle and do we really need it? In-Reply-To: <4527e4f1d7694dbd8fb9a736096e70a2@student.hpi.uni-potsdam.de> References: <4527e4f1d7694dbd8fb9a736096e70a2@student.hpi.uni-potsdam.de> Message-ID: A file handle can be a capability (*). A file name is a string. The Squeak process may lack the permissions to open a named file, but could still read from an open handle (which maybe was created by the OS using a direct user gesture). That way, a sandboxed app can only access files that were explicitly granted permission by the user, rather than all files on the disk. Secondly, it allows the use of temporary files - the file can be opened (which creates the handle) and deleted (which deletes its directory entry). The contents can still be read from the handle afterwards (at least on unix) Vanessa (*) https://en.wikipedia.org/wiki/Capability-based_security On Wed, Aug 19, 2020 at 11:26 AM Thiede, Christoph < Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > Hi all, > > > as some of you already might have noticed [1, 2], I am currently working > at a more powerful Drag and Drop (DnD) handling at the VM level of Squeak, > heavily inspired by Marcel's ideas. While studying the existing source > code, I was wondering what is the actual purpose of primitiveDropRequestFileHandle > compared to primitiveDropRequestFileName which both are called by > StandardFileStream >> #requestDropStream:. > > I had a very short look at all the different DropPlugin implementations > and in a nutshell, dropRequestFileHandle appears to call dropRequestFileName > and then sqFileOpen() that path using the FilePlugin. Compared to this, > the regular primitiveFileOpen from the FilePlugin which is called by > StandardFileStream >> #open:forWrite: leads to fileOpenNamesizewritesecure() > which first performs some ominous security checks (basically whether the > file path is valid and the file is writable if needed) and then, again, > calls sqFileOpen(). > > > So at the end of the day, both primitives appear to call the same logic. > So please allow me my naive question: Does anyone remember or imagine any > good reason why we have an additional primitive for this purpose? My > overall guess (from what I have learned so far about the VM side) would > have been that you should be as frugal as possible when it comes to > introducing a primitive, because developing, debugging, and exploring VM > code is so much less simple and intuitive than Smalltalk code. For this > reason, I would not expect to find any redundant "convenience primitives" > in the OSVM interface. > > > I have two hypothetical explanations so far which however both I do not > find satisfying: > > > > - *Optimization:* Could there have been some ancient times where it > might have been wise to save a redundant call to the SecurityPlugin after > you have got a trusted file path from the host system? > - *Buggy SecurityPlugin:* Could there be any situation in which the > SecurityPlugin would refuse a special file path returned by the DropPlugin > though it can be opened by sqFileOpen()? But I cannot experience such a > situation. > > > > *Tl;dr:* What is the reason for the existence of primitiveDropRequestFileHandle > and should it still be used? Why not simply nuke it and always use primitiveDropRequestFileName > + primitiveFileOpen? Looking forward to your suggestions! > > Best, > Christoph > > [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508 > [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/514 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From LEnglish5 at cox.net Thu Aug 20 07:19:41 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Thu, 20 Aug 2020 00:19:41 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: References: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> <06140EBB-871F-4B72-9996-17E161DC8E80@cox.net> Message-ID: <151DD396-3602-4F88-AB23-57273C3402FC@cox.net> If you look at the FFIPrim bundle, it looks different. I still can’t get anything to work except those bundles that are included with the all-in-one. L This is with Cataina. L > On Aug 19, 2020, at 12:31 AM, Tobias Pape wrote: > > Hi > >> On 16.08.2020, at 09:36, LawsonEnglish wrote: >> >> Running otool -L on my dylib: >> >> otool -L otool -L libFFITest.dylib >> libFFITest.dylib: >> /libFFITest.dylib (compatibility version 1.0.0, current version 1.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) >> >> however, running it on the executable int eh SqueakFFIPrims.bundle: >> >> otool -L SqueakFFIPrims >> SqueakFFIPrims: >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2) >> >> >> I’m not sure what the difference means. I can sorta remove /libFFITest.dylib but the "(compatibility version 1.0.0, current version 1.0.0)” remains, and I still get the same error whether or not /libFFITest.dylib is present. >> >> > > there's a stark difference, sadly. > The Plugins, which are bundles on macOS, are _not_ simply dynamic libs: > > > [Squeak.app/Contents/Resources]$ otool -L CameraPlugin.bundle/Contents/MacOS/CameraPlugin > CameraPlugin.bundle/Contents/MacOS/CameraPlugin: > /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation (compatibility version 1.0.0, current version 2.0.0) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1450.15.0) > /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1129.5.0) > /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1450.15.0) > /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0) > /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0) > /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) > > [Squeak.app/Contents/Resources]$ file CameraPlugin.bundle/Contents/MacOS/CameraPlugin > CameraPlugin.bundle/Contents/MacOS/CameraPlugin: Mach-O 64-bit bundle x86_64 > > Dynamic libs look differently: > > [~]$ otool -L /usr/lib/libbz2.dylib > /usr/lib/libbz2.dylib: > /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2) > > [~]$ file /usr/lib/libbz2.dylib > /usr/lib/libbz2.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [i386:Mach-O dynamically linked shared library i386] > /usr/lib/libbz2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 > /usr/lib/libbz2.dylib (for architecture i386): Mach-O dynamically linked shared library i386 > > =-=-= > > I would suggest you first try to call a known function in a known library. For example: > > const char* BZ2_bzlibVersion(void); from libbzip2. > > > =-=-= > > Other than that, I can't help without some artifact to look at, sorry :/ > > Best regards > -Tobias > > > >> >> Can you give me a hint as to what the output from otool -L should look like for a dylib that is useable from within /Resources? >> >> L >> >> >>> On Aug 14, 2020, at 9:19 PM, Eliot Miranda wrote: >>> >>> Hi Lawson, >>> >>>> On Aug 14, 2020, at 6:21 PM, LawsonEnglish wrote: >>>> >>>> I’m not saying it isn’t stable. >>> >>> I know. I was just saying I don’t think anything has been broken recently, so the issue is not in the FFI per se. >>> >>>> However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. >>> >>> There’s a SqueakFFIPlugin dylib (a dylib in all but name) in SqueakFFIPlugin.bundle/Contents/MacOS/SqueakFFIPlugin. That’s what the FFI actually loads. >>> >>>> I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. >>>> >>>> SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? >>> >>> Yes. >>> >>>> I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. >>>> >>>> WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. >>>> >>>> WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? >>> >>> Yes, and it is extremely tricky. I’ve been using libav and libffmpeg and others. I’ve found one has to examine carefully the output of otool -L and use install_name_tool to change the hard-coded paths of any other non-system Dublin’s a Bykov depends on and make sure one understands and uses @rpath. If your dylib uses any other dylib you’re going to have to do the same exploration. >>> >>>> >>>> I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. >>> >>> Look at the vm build makefiles for macos; they do this and they can be configured to generate dylibs in a directory, etc. >>> >>> So first question, what’s the output of >>> otool -L mylib >>> >>> (You can omit all the /System/Library ones) >>> >>>> L >>>> >>>>> On Aug 14, 2020, at 6:14 PM, Eliot Miranda wrote: >>>>> >>>>> Hi Lawson, >>>>> >>>>>> >>>>>> I realize that the test library works, but I can’t use ANY kind of library user specified/user made library for FFI with Squeak on Catalina OR Mojave, and I can’t tell what I am doing wrong. >>>>>> >>>>>> I let Craig Latta watch me, via screen sharing on skype, set up the whole thing from scratch, and his response was to start to coach me in how to create and use the VM with a c-debugger. >>>>>> >>>>>> So I don’t think I’m doing anything obviously wrong or at least Craig didn’t catch it while he watched. >>>>>> >>>>>> Still don’t have the VM working, so I thought I ask if anyone has actually done it lately? The FFIPrim libray is in a .bundle, which may or may not be signficiant to this issue. >>>>> >>>>> The FFI tests work out if the biz for me on MacOS 64-bit. The test functions are included in the FFI plugin. I haven’t tried x86/32-bit in a while but I’d be surprised if this was broken. The code is stable. >>>>> >>>>>> >>>>>> >>>>>> L >>>>>> >>>>> >>>> >>>> >>> >> >> > > > From Das.Linux at gmx.de Thu Aug 20 07:31:11 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Thu, 20 Aug 2020 09:31:11 +0200 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: <151DD396-3602-4F88-AB23-57273C3402FC@cox.net> References: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> <06140EBB-871F-4B72-9996-17E161DC8E80@cox.net> <151DD396-3602-4F88-AB23-57273C3402FC@cox.net> Message-ID: > On 20.08.2020, at 09:19, LawsonEnglish wrote: > > If you look at the FFIPrim bundle, it looks different. > > I still can’t get anything to work except those bundles that are included with the all-in-one. > > > L > > This is with Cataina. > > L Can you share the source of your test library? best regards -tobias > >> On Aug 19, 2020, at 12:31 AM, Tobias Pape wrote: >> >> Hi >> >>> On 16.08.2020, at 09:36, LawsonEnglish wrote: >>> >>> Running otool -L on my dylib: >>> >>> otool -L otool -L libFFITest.dylib >>> libFFITest.dylib: >>> /libFFITest.dylib (compatibility version 1.0.0, current version 1.0.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) >>> >>> however, running it on the executable int eh SqueakFFIPrims.bundle: >>> >>> otool -L SqueakFFIPrims >>> SqueakFFIPrims: >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2) >>> >>> >>> I’m not sure what the difference means. I can sorta remove /libFFITest.dylib but the "(compatibility version 1.0.0, current version 1.0.0)” remains, and I still get the same error whether or not /libFFITest.dylib is present. >>> >>> >> >> there's a stark difference, sadly. >> The Plugins, which are bundles on macOS, are _not_ simply dynamic libs: >> >> >> [Squeak.app/Contents/Resources]$ otool -L CameraPlugin.bundle/Contents/MacOS/CameraPlugin >> CameraPlugin.bundle/Contents/MacOS/CameraPlugin: >> /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation (compatibility version 1.0.0, current version 2.0.0) >> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1450.15.0) >> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1129.5.0) >> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1450.15.0) >> /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0) >> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0) >> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) >> >> [Squeak.app/Contents/Resources]$ file CameraPlugin.bundle/Contents/MacOS/CameraPlugin >> CameraPlugin.bundle/Contents/MacOS/CameraPlugin: Mach-O 64-bit bundle x86_64 >> >> Dynamic libs look differently: >> >> [~]$ otool -L /usr/lib/libbz2.dylib >> /usr/lib/libbz2.dylib: >> /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2) >> >> [~]$ file /usr/lib/libbz2.dylib >> /usr/lib/libbz2.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [i386:Mach-O dynamically linked shared library i386] >> /usr/lib/libbz2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 >> /usr/lib/libbz2.dylib (for architecture i386): Mach-O dynamically linked shared library i386 >> >> =-=-= >> >> I would suggest you first try to call a known function in a known library. For example: >> >> const char* BZ2_bzlibVersion(void); from libbzip2. >> >> >> =-=-= >> >> Other than that, I can't help without some artifact to look at, sorry :/ >> >> Best regards >> -Tobias >> >> >> >>> >>> Can you give me a hint as to what the output from otool -L should look like for a dylib that is useable from within /Resources? >>> >>> L >>> >>> >>>> On Aug 14, 2020, at 9:19 PM, Eliot Miranda wrote: >>>> >>>> Hi Lawson, >>>> >>>>> On Aug 14, 2020, at 6:21 PM, LawsonEnglish wrote: >>>>> >>>>> I’m not saying it isn’t stable. >>>> >>>> I know. I was just saying I don’t think anything has been broken recently, so the issue is not in the FFI per se. >>>> >>>>> However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. >>>> >>>> There’s a SqueakFFIPlugin dylib (a dylib in all but name) in SqueakFFIPlugin.bundle/Contents/MacOS/SqueakFFIPlugin. That’s what the FFI actually loads. >>>> >>>>> I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. >>>>> >>>>> SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? >>>> >>>> Yes. >>>> >>>>> I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. >>>>> >>>>> WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. >>>>> >>>>> WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? >>>> >>>> Yes, and it is extremely tricky. I’ve been using libav and libffmpeg and others. I’ve found one has to examine carefully the output of otool -L and use install_name_tool to change the hard-coded paths of any other non-system Dublin’s a Bykov depends on and make sure one understands and uses @rpath. If your dylib uses any other dylib you’re going to have to do the same exploration. >>>> >>>>> >>>>> I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. >>>> >>>> Look at the vm build makefiles for macos; they do this and they can be configured to generate dylibs in a directory, etc. >>>> >>>> So first question, what’s the output of >>>> otool -L mylib >>>> >>>> (You can omit all the /System/Library ones) >>>> >>>>> L >>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> > > From Patrick.Rein at hpi.de Thu Aug 20 08:01:06 2020 From: Patrick.Rein at hpi.de (Rein, Patrick) Date: Thu, 20 Aug 2020 08:01:06 +0000 Subject: [squeak-dev] Parser Pragma Issue and Fix In-Reply-To: References: <1f4f306849d24b75996f9a9ae8a8372e@hpi.de>, Message-ID: <4e6eb94bd5d241d4a329a6741f6633fe@hpi.de> Ah thanks a lot Levente!!! I had a test case covering that during exploring the issue but somehow discarded it at one point. I'll see to adjusting the tests and merging the change in the next few days. (The hereType == #binary solution is not perfect, as the bracket does not serve as a binary message here, but anything more sophisticated would probably require major changes to the Scanner which is not worth the effort, I think) Bests Patrick ________________________________________ From: Squeak-dev on behalf of Levente Uzonyi Sent: Tuesday, August 18, 2020 9:49:38 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] Parser Pragma Issue and Fix Hi Patrick, On Mon, 17 Aug 2020, Rein, Patrick wrote: > Hi everyone, > > while working on a parser framework I recently discovered an issue when parsing the following method: > > someTestMethod > '<' first > > This method can not be parsed by the current Squeak parser, as it expects a closing angle bracket after the message send. The parser misinterprets the bracket in the string as the beginning of a pragma. The fault is in the Parser class which did not respect the type of the token to be parsed. The attached changeset is a proposed fix for the fault. It boils down to checking for the #binary token type in the the responsible parser method: > > Parser>>#pragmaSequence > "Parse a sequence of method pragmas." > > [ (hereType == #binary and: [self matchToken: #<]) > ifFalse: [ ^ self ]. > self pragmaStatement. > (self matchToken: #>) > ifFalse: [ ^ self expected: '>' ] ] repeat > > As this is somewhat of a fundamental change, I wanted to bring this up for discussion before merging it. The issue exists the other way around with the closing bracket as well. After applying your fix compile: someTestMethod ' ^1 The same fix seems to work there too: ... (hereType == #binary and: [self matchToken: #>]) ifFalse: [ ^ self expected: '>' ] ] repeat Levente > > Thanks and best wishes, > Patrick From commits at source.squeak.org Thu Aug 20 08:19:15 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 08:19:15 0000 Subject: [squeak-dev] The Trunk: Compiler-pre.441.mcz Message-ID: Patrick Rein uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-pre.441.mcz ==================== Summary ==================== Name: Compiler-pre.441 Author: pre Time: 20 August 2020, 10:19:13.607828 am UUID: 25de8b68-cea6-db46-9d6a-f400bd5f8b82 Ancestors: Compiler-eem.440 Fixes an issue with pragma parsing matching a string or symbol literal with an angle bracket as an opening pragma bracket and correspondingly a closing string or symbol literal as a closing pragma. =============== Diff against Compiler-eem.440 =============== Item was changed: ----- Method: Parser>>pragmaSequence (in category 'pragmas') ----- pragmaSequence "Parse a sequence of method pragmas." + [ (hereType == #binary and: [self matchToken: #<]) - [ - (self matchToken: #<) ifFalse: [ ^ self ]. self pragmaStatement. + (hereType == #binary and: [self matchToken: #>]) - (self matchToken: #>) ifFalse: [ ^ self expected: '>' ] ] repeat! From commits at source.squeak.org Thu Aug 20 08:20:43 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 08:20:43 0000 Subject: [squeak-dev] The Trunk: Tests-pre.436.mcz Message-ID: Patrick Rein uploaded a new version of Tests to project The Trunk: http://source.squeak.org/trunk/Tests-pre.436.mcz ==================== Summary ==================== Name: Tests-pre.436 Author: pre Time: 20 August 2020, 10:20:39.808828 am UUID: 19d0bec2-5710-1a42-9dda-8bb0cadbf1b0 Ancestors: Tests-mt.435 Adds regression tests for a parser issue with pragma parsing matching a string or symbol literal with an angle bracket as an opening pragma bracket and correspondingly a closing string or symbol literal as a closing pragma. =============== Diff against Tests-mt.435 =============== Item was added: + TestCase subclass: #ParserTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'Tests-Compiler'! Item was added: + ----- Method: ParserTest>>testRegressionPragmasParsing (in category 'tests - pragmas') ----- + testRegressionPragmasParsing + + self + shouldnt: [Parser new + parse: 'methodHeader + ' + class: ParserTest] + raise: SyntaxErrorNotification! Item was added: + ----- Method: ParserTest>>testRegressionPragmasParsingClosingToken (in category 'tests - pragmas') ----- + testRegressionPragmasParsingClosingToken + + self + should: [Parser new + parse: 'methodHeader + ''' + class: ParserTest] + raise: SyntaxErrorNotification! Item was added: + ----- Method: ParserTest>>testRegressionPragmasParsingIsTooPossessive (in category 'tests - pragmas') ----- + testRegressionPragmasParsingIsTooPossessive + "The parser might interpret angle bracket literals as opening pragmas" + + self + shouldnt: [Parser new + parse: 'methodHeader + ''<'' asciiValue' + class: ParserTest] + raise: SyntaxErrorNotification. + + self + shouldnt: [Parser new + parse: 'methodHeader + #< asciiValue' + class: ParserTest] + raise: SyntaxErrorNotification. + + self + shouldnt: [Parser new + parse: 'methodHeader + $< asciiValue' + class: ParserTest] + raise: SyntaxErrorNotification! From edgardec2005 at gmail.com Thu Aug 20 11:08:16 2020 From: edgardec2005 at gmail.com (Edgar J. De Cleene) Date: Thu, 20 Aug 2020 08:08:16 -0300 Subject: [squeak-dev] Trying to help to bring BabySRE to modern Squeak Message-ID: Finally I get BabySRE working in 6.0, without freezes and without undeclared classes. This do not means all wonderful work of Trygve is on 6.0 But is a start. Also I see a couple of pages is on swiki Still have my own expanded view on 190.191.74.232:9090 user visita no pass Load orden is TextMorphEditor from Jurasik Park era from Ladrillos repo BabySRE-Connectors BB1IDE-Support-edc.1 BB1UnmappedRole And finally BabySRE-edc.51 Also found I make several .mcz coming of original 3.10 image , so I dig some more and perhaps we have more of Trygve . So no Hasta la vista Baby. Say Volviste Baby (You come back Baby) Edgar @morplenauta -------------- next part -------------- A non-text attachment was scrubbed... Name: AgregaRepoLadrillos.st Type: application/octet-stream Size: 183 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: BB1UnmappedRole.cs.gz URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Thu Aug 20 11:41:25 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Thu, 20 Aug 2020 11:41:25 +0000 Subject: [squeak-dev] What is primitiveDropRequestFileHandle and do we really need it? In-Reply-To: References: <4527e4f1d7694dbd8fb9a736096e70a2@student.hpi.uni-potsdam.de>, Message-ID: Hi Vanessa, thanks for the pointer to capability-based security, this makes sense! However in the OSVM source, I could not find any implementation of dropRequestFileHandle() that would not call dropRequestFileName() and sqFileOpen(), so I believe capability-based security is not actually used at the moment. Still, this hook could be relevant when a new platform (for instance, Android?) would be supported by OSVM. So for now, I conclude that one should indeed use both primitives as implemented in the latest Trunk, in order not to comprise this possibility for future implementations. Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Vanessa Freudenberg Gesendet: Mittwoch, 19. August 2020 23:42:52 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] What is primitiveDropRequestFileHandle and do we really need it? A file handle can be a capability (*). A file name is a string. The Squeak process may lack the permissions to open a named file, but could still read from an open handle (which maybe was created by the OS using a direct user gesture). That way, a sandboxed app can only access files that were explicitly granted permission by the user, rather than all files on the disk. Secondly, it allows the use of temporary files - the file can be opened (which creates the handle) and deleted (which deletes its directory entry). The contents can still be read from the handle afterwards (at least on unix) Vanessa (*) https://en.wikipedia.org/wiki/Capability-based_security On Wed, Aug 19, 2020 at 11:26 AM Thiede, Christoph > wrote: Hi all, as some of you already might have noticed [1, 2], I am currently working at a more powerful Drag and Drop (DnD) handling at the VM level of Squeak, heavily inspired by Marcel's ideas. While studying the existing source code, I was wondering what is the actual purpose of primitiveDropRequestFileHandle compared to primitiveDropRequestFileName which both are called by StandardFileStream >> #requestDropStream:. I had a very short look at all the different DropPlugin implementations and in a nutshell, dropRequestFileHandle appears to call dropRequestFileName and then sqFileOpen() that path using the FilePlugin. Compared to this, the regular primitiveFileOpen from the FilePlugin which is called by StandardFileStream >> #open:forWrite: leads to fileOpenNamesizewritesecure() which first performs some ominous security checks (basically whether the file path is valid and the file is writable if needed) and then, again, calls sqFileOpen(). So at the end of the day, both primitives appear to call the same logic. So please allow me my naive question: Does anyone remember or imagine any good reason why we have an additional primitive for this purpose? My overall guess (from what I have learned so far about the VM side) would have been that you should be as frugal as possible when it comes to introducing a primitive, because developing, debugging, and exploring VM code is so much less simple and intuitive than Smalltalk code. For this reason, I would not expect to find any redundant "convenience primitives" in the OSVM interface. I have two hypothetical explanations so far which however both I do not find satisfying: * Optimization: Could there have been some ancient times where it might have been wise to save a redundant call to the SecurityPlugin after you have got a trusted file path from the host system? * Buggy SecurityPlugin: Could there be any situation in which the SecurityPlugin would refuse a special file path returned by the DropPlugin though it can be opened by sqFileOpen()? But I cannot experience such a situation. Tl;dr: What is the reason for the existence of primitiveDropRequestFileHandle and should it still be used? Why not simply nuke it and always use primitiveDropRequestFileName + primitiveFileOpen? Looking forward to your suggestions! Best, Christoph [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/514 -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Thu Aug 20 12:33:34 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 12:33:34 0000 Subject: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz Message-ID: A new version of 60Deprecated was added to project The Inbox: http://source.squeak.org/inbox/60Deprecated-ct.80.mcz ==================== Summary ==================== Name: 60Deprecated-ct.80 Author: ct Time: 20 August 2020, 2:33:32.63864 pm UUID: 1295269c-62ee-5c45-9315-e66ff5eef57a Ancestors: 60Deprecated-mt.79 Finnaly deprecate #doWithIndex: and #collectWithIndex:. Other packages will be patched right now. =============== Diff against 60Deprecated-mt.79 =============== Item was added: + ----- Method: HashedCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- + doWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexDo: instead'. + ^ self withIndexDo: elementAndIndexBlock! Item was added: + ----- Method: SequenceableCollection>>collectWithIndex: (in category '*60Deprecated-enumerating') ----- + collectWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexCollect: instead'. + ^ self withIndexCollect: elementAndIndexBlock! Item was added: + ----- Method: SequenceableCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- + doWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexDo: instead'. + ^ self withIndexDo: elementAndIndexBlock! Item was changed: ----- Method: StandardFileMenu>>menuSelectionsArray: (in category 'menu building') ----- menuSelectionsArray: aDirectory "Answer a menu selections object corresponding to aDirectory. The object is an array corresponding to each item, each element itself constituting a two-element array, the first element of which contains a selector to operate on and the second element of which contains the parameters for that selector." |dirSize| dirSize := aDirectory pathParts size. ^Array streamContents: [:s | canTypeFileName ifTrue: [s nextPut: (StandardFileMenuResult directory: aDirectory name: nil)]. s nextPut: (StandardFileMenuResult directory: (FileDirectory root) name: ''). + aDirectory pathParts withIndexDo: - aDirectory pathParts doWithIndex: [:d :i | s nextPut: (StandardFileMenuResult directory: (self advance: dirSize - i containingDirectoriesFrom: aDirectory) name: '')]. aDirectory directoryNames do: [:dn | s nextPut: (StandardFileMenuResult directory: (FileDirectory on: (aDirectory fullNameFor: dn)) name: '')]. aDirectory fileNames do: [:fn | pattern do: [:pat | (pat match: fn) ifTrue: [ s nextPut: (StandardFileMenuResult directory: aDirectory name: fn)]]]]! Item was changed: ----- Method: StandardFileMenu>>pathPartsString: (in category 'menu building') ----- pathPartsString: aDirectory "Answer a string concatenating the path parts strings in aDirectory, each string followed by a cr." ^String streamContents: [:s | s nextPutAll: '[]'; cr. + aDirectory pathParts asArray withIndexDo: - aDirectory pathParts asArray doWithIndex: [:part :i | s next: i put: $ . s nextPutAll: part withBlanksTrimmed; cr]]! From commits at source.squeak.org Thu Aug 20 12:34:35 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 12:34:35 0000 Subject: [squeak-dev] The Inbox: Balloon-ct.34.mcz Message-ID: A new version of Balloon was added to project The Inbox: http://source.squeak.org/inbox/Balloon-ct.34.mcz ==================== Summary ==================== Name: Balloon-ct.34 Author: ct Time: 20 August 2020, 2:34:34.01964 pm UUID: 76909964-5192-1f49-a074-e265c772e3a6 Ancestors: Balloon-nice.33 Complements 60Deprecated-ct.80 (deprecation #doWithIndex: & Co.). =============== Diff against Balloon-nice.33 =============== Item was changed: ----- Method: BalloonEngineConstants class>>initializeInstVarNames:prefixedBy: (in category 'pool definition') ----- initializeInstVarNames: aClass prefixedBy: aString | token | + aClass instVarNames withIndexDo: [:instVarName :index | | value | + token := (aString, instVarName first asUppercase asString, (instVarName copyFrom: 2 to: instVarName size), 'Index') asSymbol. - aClass instVarNames doWithIndex:[:instVarName :index| | value | - token := (aString, instVarName first asUppercase asString, (instVarName copyFrom: 2 to: instVarName size),'Index') asSymbol. value := index - 1. + (self bindingOf: token) ifNil: [self addClassVarName: token]. - (self bindingOf: token) ifNil:[self addClassVarName: token]. (self bindingOf: token) value: value. ]. + token := (aString, aClass name, 'Size') asSymbol. + (self bindingOf: token) ifNil: [self addClassVarName: token]. - token := (aString, aClass name,'Size') asSymbol. - (self bindingOf: token) ifNil:[self addClassVarName: token]. (self bindingOf: token) value: aClass instSize.! From commits at source.squeak.org Thu Aug 20 12:35:13 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 12:35:13 0000 Subject: [squeak-dev] The Inbox: Collections-ct.908.mcz Message-ID: A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-ct.908.mcz ==================== Summary ==================== Name: Collections-ct.908 Author: ct Time: 20 August 2020, 2:35:10.09764 pm UUID: b22d8a31-b3dd-ba49-924a-3f470da838c2 Ancestors: Collections-eem.907 Complements 60Deprecated-ct.80 (deprecation #doWithIndex: & Co.). =============== Diff against Collections-eem.907 =============== Item was removed: - ----- Method: HashedCollection>>doWithIndex: (in category 'enumerating') ----- - doWithIndex: aBlock2 - "Support Set enumeration with a counter, even though not ordered" - | index | - index := 0. - self do: [:item | aBlock2 value: item value: (index := index+1)]! Item was added: + ----- Method: HashedCollection>>withIndexDo: (in category 'enumerating') ----- + withIndexDo: elementAndIndexBlock + "Support Set enumeration with a counter, even though not ordered" + | index | + index := 0. + self do: [:item | elementAndIndexBlock value: item value: (index := index + 1)].! Item was removed: - ----- Method: SequenceableCollection>>collectWithIndex: (in category 'enumerating') ----- - collectWithIndex: elementAndIndexBlock - "Use the new version with consistent naming" - ^ self withIndexCollect: elementAndIndexBlock! Item was removed: - ----- Method: SequenceableCollection>>doWithIndex: (in category 'enumerating') ----- - doWithIndex: elementAndIndexBlock - "Use the new version with consistent naming" - ^ self withIndexDo: elementAndIndexBlock! Item was changed: ----- Method: String>>compressWithTable: (in category 'converting') ----- compressWithTable: tokens "Return a string with all substrings that occur in tokens replaced by a character with ascii code = 127 + token index. This will work best if tokens are sorted by size. Assumes this string contains no characters > 127, or that they are intentionally there and will not interfere with this process." | str null finalSize result ri c | null := Character null. str := self copyFrom: 1 to: self size. "Working string will get altered" finalSize := str size. + tokens withIndexDo: - tokens doWithIndex: [:token :tIndex | | start ts | start := 1. [(start := str findString: token startingAt: start) > 0] whileTrue: [ts := token size. ((start + ts) <= str size and: [(str at: start + ts) = $ and: [tIndex*2 <= 128]]) ifTrue: [ts := token size + 1. "include training blank" str at: start put: (Character value: tIndex*2 + 127)] ifFalse: [str at: start put: (Character value: tIndex + 127)]. str at: start put: (Character value: tIndex + 127). 1 to: ts-1 do: [:i | str at: start+i put: null]. finalSize := finalSize - (ts - 1). start := start + ts]]. result := String new: finalSize. ri := 0. 1 to: str size do: [:i | (c := str at: i) = null ifFalse: [result at: (ri := ri+1) put: c]]. ^ result! From commits at source.squeak.org Thu Aug 20 12:35:40 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 12:35:40 0000 Subject: [squeak-dev] The Inbox: CollectionsTests-ct.342.mcz Message-ID: A new version of CollectionsTests was added to project The Inbox: http://source.squeak.org/inbox/CollectionsTests-ct.342.mcz ==================== Summary ==================== Name: CollectionsTests-ct.342 Author: ct Time: 20 August 2020, 2:35:38.06964 pm UUID: 7e7af0d0-11d0-f847-b55d-abef876fed46 Ancestors: CollectionsTests-ul.341 Complements 60Deprecated-ct.80 (deprecation #doWithIndex: & Co.). =============== Diff against CollectionsTests-ul.341 =============== Item was changed: ----- Method: DictionaryTest>>testIntegrityOfDictionaries (in category 'tests - integrity') ----- testIntegrityOfDictionaries #( Dictionary IdentityDictionary SystemDictionary LiteralDictionary PluggableDictionary WeakValueDictionary) do: [ :dictionaryClassName | Smalltalk at: dictionaryClassName ifPresent: [ :dictionaryClass | dictionaryClass allInstancesDo: [ :dictionary | dictionary keysAndValuesDo: [ :key :value | self assert: (dictionary at: key) == value ]. + dictionary array withIndexDo: [ :association :index | - dictionary array doWithIndex: [ :association :index | association ifNotNil: [ self assert: (dictionary scanFor: association key) = index ] ] ] ] ]! From commits at source.squeak.org Thu Aug 20 12:36:47 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 12:36:47 0000 Subject: [squeak-dev] The Inbox: EToys-ct.401.mcz Message-ID: A new version of EToys was added to project The Inbox: http://source.squeak.org/inbox/EToys-ct.401.mcz ==================== Summary ==================== Name: EToys-ct.401 Author: ct Time: 20 August 2020, 2:36:39.45064 pm UUID: 5a05fe89-08aa-424a-b94a-b55283faff49 Ancestors: EToys-eem.400 Complements 60Deprecated-ct.80 (deprecation #doWithIndex: & Co.). =============== Diff against EToys-eem.400 =============== Item was changed: ----- Method: BookMorph>>saveBookForRevert (in category '*Etoys-Squeakland-master pages') ----- saveBookForRevert "Consider this the master version of the book, with regard to which pages are in it, what their order is, and what their content is" | forRevert | forRevert := OrderedCollection new. + pages withIndexDo: - pages doWithIndex: [: pg :index | pg setProperty: #revertKey toValue: index. forRevert add: (index -> pg copy)]. self setProperty:# pagesForRevert toValue: forRevert! Item was changed: ----- Method: Chess960Morph>>reinstallPieces (in category 'resizing') ----- reinstallPieces + board whitePlayer pieces withIndexDo: [:pc :n | - board whitePlayer pieces doWithIndex: [:pc :n | pc isZero ifFalse: [ self addedPiece: pc at: n white: true]]. + board blackPlayer pieces withIndexDo: [:pc :n | - board blackPlayer pieces doWithIndex: [:pc :n | pc isZero ifFalse: [ self addedPiece: pc at: n white: false]].! Item was changed: ----- Method: Chess960Player>>addBlackPieces: (in category 'adding/removing') ----- addBlackPieces: aChess960Configuration self configuration: aChess960Configuration. + configuration positions withIndexDo: [:p :n | self addPiece: p at: 56+n]. - configuration positions doWithIndex: [:p :n | self addPiece: p at: 56+n]. 49 to: 56 do:[:i| self addPiece: Pawn at: i].! Item was changed: ----- Method: Chess960Player>>addWhitePieces: (in category 'adding/removing') ----- addWhitePieces: aChess960Configuration self configuration: aChess960Configuration. + configuration positions withIndexDo: [:p :n | self addPiece: p at: n]. - configuration positions doWithIndex: [:p :n | self addPiece: p at: n]. 9 to: 16 do:[:i| self addPiece: Pawn at: i]. ! Item was changed: ----- Method: ChineseCheckers>>drawOn: (in category 'drawing') ----- drawOn: aCanvas | row1 row2 offset dotExtent | super drawOn: aCanvas. "Draw square board" "Only draw rows in the clipping region" dotExtent := (self width//25) asPoint. offset := self pieceSize - dotExtent + 1 // 2. "Offset of smaller dots rel to larger" row1 := (self boardLocAt: aCanvas clipRect topLeft) x max: 1. row2 := (self boardLocAt: aCanvas clipRect bottomRight) x min: board size. row1 to: row2 do: + [:row | (board at: row) withIndexDo: - [:row | (board at: row) doWithIndex: [:cell :i | cell ifNotNil: [aCanvas fillOval: ((self cellPointAt: (row at i)) + offset extent: dotExtent) color: (colors at: cell+1)]]]! Item was changed: ----- Method: CipherPanel>>encodedQuote: (in category 'initialization') ----- encodedQuote: aString "World addMorph: CipherPanel new" | morph prev | aString isEmpty ifTrue: [^ self]. (letterMorphs isNil or: [self isClean]) ifFalse: [(self confirm: 'Are you sure you want to discard all typing?' translated) ifFalse: [^ self]]. haveTypedHere := false. quote := aString asUppercase. prev := nil. originalMorphs := quote asArray + withIndexCollect: [:c :i | WordGameLetterMorph new plain indexInQuote: i id1: nil; - collectWithIndex: [:c :i | WordGameLetterMorph new plain indexInQuote: i id1: nil; setLetter: (quote at: i)]. letterMorphs := OrderedCollection new. decodingMorphs := quote asArray + withIndexCollect: [:c :i | (quote at: i) isLetter - collectWithIndex: [:c :i | (quote at: i) isLetter ifTrue: [morph := WordGameLetterMorph new underlined indexInQuote: i id1: nil. morph on: #mouseDown send: #mouseDownEvent:letterMorph: to: self. morph on: #keyStroke send: #keyStrokeEvent:letterMorph: to: self. letterMorphs addLast: morph. morph predecessor: prev. prev ifNotNil: [prev successor: morph]. prev := morph] ifFalse: [WordGameLetterMorph new plain indexInQuote: i id1: nil; setLetter: (quote at: i)]]. self color: originalMorphs first color. self extent: 500 @ 500! Item was changed: ----- Method: DocLibrary>>saveDocCheck: (in category 'doc pane') ----- saveDocCheck: aMorph "Make sure the document gets attached to the version of the code that the user was looking at. Is there a version of this method in a changeSet beyond the updates we know about? Works even when the user has internal update numbers and the documentation is for external updates (It always is)." | classAndMethod parts selector class lastUp beyond ours docFor unNum ok key verList ext response | classAndMethod := aMorph valueOfProperty: #classAndMethod. classAndMethod ifNil: [ ^ self error: 'need to know the class and method']. "later let user set it" parts := classAndMethod findTokens: ' .'. selector := parts last asSymbol. class := Smalltalk at: (parts first asSymbol) ifAbsent: [^ self saveDoc: aMorph]. parts size = 3 ifTrue: [class := class class]. "Four indexes we are looking for: docFor = highest numbered below lastUpdate that has method. unNum = a higher unnumbered set that has method. lastUp = lastUpdate we know about in methodVersions beyond = any set about lastUp that has the method." + ChangeSet allChangeSets withIndexDo: [:cs :ind | "youngest first" - ChangeSet allChangeSets doWithIndex: [:cs :ind | "youngest first" (cs name includesSubstring: lastUpdateName) ifTrue: [lastUp := ind]. (cs atSelector: selector class: class) ~~ #none ifTrue: [ lastUp ifNotNil: [beyond := ind. ours := cs name] ifNil: [cs name first isDigit ifTrue: [docFor := ind] ifFalse: [unNum := ind. ours := cs name]]]]. "See if version the user sees is the version he is documenting" ok := beyond == nil. unNum ifNotNil: [docFor ifNotNil: [ok := docFor > unNum] ifNil: [ok := false]]. "old changeSets gone" ok ifTrue: [^ self saveDoc: aMorph]. key := DocLibrary properStemFor: classAndMethod. verList := (methodVersions at: key ifAbsent: [#()]), #(0 0). ext := verList first. "external update number we will write to" response := (PopUpMenu labels: 'Cancel\Broadcast Page' withCRs) startUpWithCaption: 'You are documenting a method in External Update ', ext asString, '.\There is a more recent version of that method in ' withCRs, ours, '.\If you are explaining the newer version, please Cancel.\Wait until that version appears in an External Update.' withCRs. response = 2 ifTrue: [self saveDoc: aMorph]. ! Item was changed: ----- Method: EventRollMorph>>setMediaEventMorphs (in category 'display') ----- setMediaEventMorphs "Place morphs representing the media track on the roll." | aMorph aWheel | mediaTrack ifEmpty: [^ self]. aWheel := Color wheel: mediaTrack size. + mediaTrack withIndexDo: - mediaTrack doWithIndex: [:evt :index | aMorph := MediaEventMorph new. aMorph hResizing: #shrinkWrap. aMorph vResizing: #shrinkWrap. aMorph color: ((aWheel at: index) alpha: 0.5). aMorph event: evt. aMorph extent: ((evt durationInMilliseconds / millisecondsPerPixel) @ 32). aMorph left: ((evt timeStamp - startTime)/ millisecondsPerPixel). aMorph top: 84. actualRoll addMorphBack: aMorph]! Item was changed: ----- Method: MentoringEventRecorder>>mergeMediaEvent: (in category 'event handling') ----- mergeMediaEvent: anEvent "Merge the event, presently time-stamped with a relative time-stamp., with my existing tape. Answer the merged tape. It is the responsibility of the sender to notify other objects that may be interested in the change, such as an event roll." | itsTimeStamp eventFollowingIt newTape anIndex itsCopy copysTimeStamp | itsTimeStamp := anEvent timeStamp. itsCopy := anEvent copy. itsCopy timeStamp: (copysTimeStamp := itsTimeStamp + tape first timeStamp). eventFollowingIt := tape detect: [:evt | evt timeStamp > copysTimeStamp] ifNone: [nil]. anIndex := eventFollowingIt ifNil: [tape size + 1] ifNotNil: [tape indexOf: eventFollowingIt]. newTape := Array streamContents: [:aStream | + tape withIndexDo: - tape doWithIndex: [:evt :index | index = anIndex ifTrue: [aStream nextPut: itsCopy]. aStream nextPut: evt]. anIndex > tape size ifTrue: [aStream nextPut: itsCopy]]. tape := newTape! Item was changed: ----- Method: MouseEventEditor>>initializeFor:forEventRoll: (in category 'initialization') ----- initializeFor: aMouseEventSequenceMorph forEventRoll: aRoll "Initialize the receiver as an editor for the given mouse-event-sequence and event-roll." | aTheatre aMorph | self color: (Color green muchLighter alpha: 0.7). aTheatre := aRoll eventTheatre. mouseEventSequenceMorph := aMouseEventSequenceMorph. self extent: aTheatre initialContentArea extent. self setNameTo: 'mouse event editor'. + mouseEventSequenceMorph events withIndexDo: - mouseEventSequenceMorph events doWithIndex: [:evt :index | aMorph := self discRepresentingEvent: evt index: index. aMorph center: evt position - aTheatre initialContentArea topLeft. self addMorphFront: aMorph]! Item was changed: ----- Method: Player>>absorbBackgroundDataFrom:forInstanceVariables: (in category 'slots-kernel') ----- absorbBackgroundDataFrom: aLine forInstanceVariables: slotNames "Fill my background fields from the substrings in a tab-delimited line of data. At the moment this only really cateres to string-valued items" + slotNames withIndexDo: - slotNames doWithIndex: [:aSlotName :anIndex | aLine do: [:aValue | self instVarNamed: aSlotName put: aValue] toFieldNumber: anIndex]! Item was changed: ----- Method: Player>>universalTilesForInterface: (in category 'scripts-kernel') ----- universalTilesForInterface: aMethodInterface "Return universal tiles for the given method interface. Record who self is." | ms itsSelector argList makeSelfGlobal phrase aType | itsSelector := aMethodInterface selector. argList := OrderedCollection new. + aMethodInterface argumentVariables withIndexDo: - aMethodInterface argumentVariables doWithIndex: [:anArgumentVariable :anIndex | | argTile | argTile := ScriptingSystem tileForArgType: (aType := aMethodInterface typeForArgumentNumber: anIndex). argList add: (aType == #Player ifTrue: [argTile actualObject] ifFalse: [argTile literal]). "default value for each type"]. ms := MessageSend receiver: self selector: itsSelector arguments: argList asArray. "For CardPlayers, use 'self'. For others, name me, and use my global name." makeSelfGlobal := self class officialClass ~~ CardPlayer. phrase := ms asTilesIn: self class globalNames: makeSelfGlobal. makeSelfGlobal ifFalse: [phrase setProperty: #scriptedPlayer toValue: self]. ^ phrase ! Item was changed: ----- Method: QuickGuideMorph class>>getWordyName:forCategory: (in category 'initialization') ----- getWordyName: guideName forCategory: guideCategory "With guideName and category already filled in, make a name in words. Remove the cat name, and trailing digits. Separate words at capital letters. NavBarHowToUse3 -> 'How To Use' " | gn mm tt | gn := guideName allButFirst: guideCategory size. gn := gn withoutTrailingDigits. mm := gn size. + gn reversed withIndexDo: [:cc :ind | - gn reversed doWithIndex: [:cc :ind | ind < mm ifTrue: [ cc isUppercase ifTrue: [ tt := mm + 1 - ind. gn := (gn copyFrom: 1 to: tt-1), ' ', (gn copyFrom: tt to: gn size)]. cc == $- ifTrue: [ tt := mm + 1 - ind. gn at: tt put: $ ]. "convert dash to space" ]]. ^ gn! Item was changed: ----- Method: ScriptEditorMorph>>indexOfMorphAbove: (in category 'dropping/grabbing') ----- indexOfMorphAbove: aPoint "Return index of lowest morph whose bottom is above aPoint. Will return 0 if the first morph is not above aPoint" + submorphs withIndexDo: - submorphs doWithIndex: [:m :i | m fullBounds bottom >= aPoint y ifTrue: [^ (i max: firstTileRow) - 1]]. ^ submorphs size! Item was changed: ----- Method: ScriptEditorMorph>>reinsertSavedTiles: (in category 'other') ----- reinsertSavedTiles: savedTiles "Revert the scriptor to show the saved tiles" + self submorphs withIndexDo: [:m :i | i > 1 ifTrue: [m delete]]. - self submorphs doWithIndex: [:m :i | i > 1 ifTrue: [m delete]]. self addAllMorphs: savedTiles. self allMorphsDo: [:m | m isTileScriptingElement ifTrue: [m bringUpToDate]]. self install. self showingMethodPane: false! Item was changed: ----- Method: SmalltalkImage>>macVmMajorMinorBuildVersion (in category '*Etoys-Squeakland-system attribute') ----- macVmMajorMinorBuildVersion "SmalltalkImage current macVmMajorMinorBuildVersion" | aString rawTokens versionPart versionTokens versionArray | aString := self vmVersion. aString ifNil: [^ #(0 0 0)]. rawTokens := ((aString copyAfterLast: $]) findTokens: $ ). versionPart := rawTokens detect: [:each | each includes: $.] ifNone: [^#(0 0 0)]. versionTokens := versionPart findTokens: $.. + versionArray := #(0 0 0) withIndexCollect: [:each :index | - versionArray := #(0 0 0) collectWithIndex: [:each :index | (versionTokens at: index ifAbsent:['']) initialIntegerOrNil ifNil: [each]]. ^versionArray! Item was changed: ----- Method: StackMorph>>getAllText (in category 'menu') ----- getAllText "Collect the text for each card. Just point at strings so don't have to recopy them. (Parallel array of urls for ID of cards. Remote cards not working yet.) allText = Array (cards size) of arrays (fields in it) of strings of text. allTextUrls = Array (cards size) of urls or card numbers." | oldUrls oldStringLists allText allTextUrls | self writeSingletonData. oldUrls := self valueOfProperty: #allTextUrls ifAbsent: [#()]. oldStringLists := self valueOfProperty: #allText ifAbsent: [#()]. allText := self privateCards collect: [:pg | OrderedCollection new]. allTextUrls := Array new: self privateCards size. + self privateCards withIndexDo: [:aCard :ind | | aUrl which | - self privateCards doWithIndex: [:aCard :ind | | aUrl which | aUrl := aCard url. aCard isInMemory ifTrue: [(allText at: ind) addAll: (aCard allStringsAfter: nil). aUrl ifNil: [aUrl := ind]. allTextUrls at: ind put: aUrl] ifFalse: ["Order of cards on server may be different. (later keep up to date?)" "*** bug in this algorithm if delete a page?" which := oldUrls indexOf: aUrl. allTextUrls at: ind put: aUrl. which = 0 ifFalse: [allText at: ind put: (oldStringLists at: which)]]]. self setProperty: #allText toValue: allText. self setProperty: #allTextUrls toValue: allTextUrls. ^ allText! From commits at source.squeak.org Thu Aug 20 12:37:39 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 12:37:39 0000 Subject: [squeak-dev] The Inbox: Graphics-ct.434.mcz Message-ID: A new version of Graphics was added to project The Inbox: http://source.squeak.org/inbox/Graphics-ct.434.mcz ==================== Summary ==================== Name: Graphics-ct.434 Author: ct Time: 20 August 2020, 2:37:30.64764 pm UUID: 87f9dca3-539e-8b47-8913-64d06da67c73 Ancestors: Graphics-mt.433 Complements 60Deprecated-ct.80 (deprecation #doWithIndex: & Co.). =============== Diff against Graphics-mt.433 =============== Item was changed: ----- Method: Color class>>colorFrom: (in category 'instance creation') ----- colorFrom: parm "Return an instantiated color from parm. If parm is already a color, return it, else return the result of my performing it if it's a symbol or, if it is a list, it can either be an array of three numbers, which will be interpreted as RGB values, or a list of symbols, the first of which is sent to me and then the others of which are in turn sent to the prior result, thus allowing entries of the form #(blue darker). Else just return the thing" | aColor firstParm | (parm isKindOf: Color) ifTrue: [^ parm]. (parm isSymbol) ifTrue: [^ self perform: parm]. (parm isString) ifTrue: [^ self fromString: parm]. ((parm isKindOf: SequenceableCollection) and: [parm size > 0]) ifTrue: [firstParm := parm first. (firstParm isKindOf: Number) ifTrue: [^ self fromRgbTriplet: parm]. aColor := self colorFrom: firstParm. + parm withIndexDo: - parm doWithIndex: [:sym :ind | ind > 1 ifTrue: [aColor := aColor perform: sym]]. ^ aColor]. ^ parm " Color colorFrom: #(blue darker) Color colorFrom: Color blue darker Color colorFrom: #blue Color colorFrom: #(0.0 0.0 1.0) "! Item was changed: ----- Method: ColorForm>>colorsUsed (in category 'color manipulation') ----- colorsUsed "Return a list of the colors actually used by this ColorForm." | myColor list | myColor := self colors. list := OrderedCollection new. + self tallyPixelValues withIndexDo: [:count :i | - self tallyPixelValues doWithIndex: [:count :i | count > 0 ifTrue: [list add: (myColor at: i)]]. ^ list asArray ! Item was changed: ----- Method: Form>>cgForPixelValue:orNot: (in category 'analyzing') ----- cgForPixelValue: pv orNot: not "Return the center of gravity for all pixels of value pv. Note: If orNot is true, then produce the center of gravity for all pixels that are DIFFERENT from the supplied (background) value" | xAndY | xAndY := (Array with: (self xTallyPixelValue: pv orNot: not) with: (self yTallyPixelValue: pv orNot: not)) collect: [:profile | | pixCount weighted | "For both x and y profiles..." pixCount := 0. weighted := 0. + profile withIndexDo: - profile doWithIndex: [:t :i | pixCount := pixCount + t. weighted := weighted + (t*i)]. pixCount = 0 "Produce average of nPixels weighted by coordinate" ifTrue: [0.0] ifFalse: [weighted asFloat / pixCount asFloat - 1.0]]. ^ xAndY first @ xAndY last " | f cg | [Sensor anyButtonPressed] whileFalse: [f := Form fromDisplay: (Sensor cursorPoint extent: 50 at 50). cg := f cgForPixelValue: (Color black pixelValueForDepth: f depth) orNot: false. f displayAt: 0 at 0. Display fill: (cg extent: 2 at 2) fillColor: Color red]. ScheduledControllers restore "! Item was changed: ----- Method: Form>>colorsUsed (in category 'analyzing') ----- colorsUsed "Return a list of the Colors this form uses." | tallies tallyDepth usedColors | tallies := self tallyPixelValues. tallyDepth := (tallies size log: 2) asInteger. usedColors := OrderedCollection new. + tallies withIndexDo: [:count :i | - tallies doWithIndex: [:count :i | count > 0 ifTrue: [ usedColors add: (Color colorFromPixelValue: i - 1 depth: tallyDepth)]]. ^ usedColors asArray ! Item was changed: ----- Method: FormSetFont>>fromFormArray:asciiStart:ascent: (in category 'initialize-release') ----- fromFormArray: formArray asciiStart: asciiStart ascent: ascentVal | height width x badChar | type := 2. name := 'aFormFont'. minAscii := asciiStart. maxAscii := minAscii + formArray size - 1. ascent := ascentVal. subscript := superscript := emphasis := 0. height := width := 0. maxWidth := 0. formArray do: [:f | width := width + f width. maxWidth := maxWidth max: f width. height := height max: f height + f offset y]. badChar := (Form extent: 7 at height) borderWidth: 1. width := width + badChar width. descent := height - ascent. pointSize := height. glyphs := Form extent: width @ height depth: formArray first depth. xTable := Array new: maxAscii + 3 withAll: 0. x := 0. + formArray withIndexDo: - formArray doWithIndex: [:f :i | f displayOn: glyphs at: x at 0. xTable at: minAscii + i+1 put: (x := x + f width)]. badChar displayOn: glyphs at: x at 0. xTable at: maxAscii + 3 put: x + badChar width. characterToGlyphMap := nil.! From commits at source.squeak.org Thu Aug 20 12:38:08 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 12:38:08 0000 Subject: [squeak-dev] The Inbox: Kernel-ct.1337.mcz Message-ID: A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1337.mcz ==================== Summary ==================== Name: Kernel-ct.1337 Author: ct Time: 20 August 2020, 2:38:04.66564 pm UUID: f4a90a1e-f869-4b43-b786-d451978cba31 Ancestors: Kernel-dtl.1336 Complements 60Deprecated-ct.80 (deprecation #doWithIndex: & Co.). =============== Diff against Kernel-dtl.1336 =============== Item was changed: ----- Method: ClassDescription>>forceNewFrom: (in category 'instance variables') ----- forceNewFrom: anArray "Create a new instance of the class and fill its instance variables up with the array." | object max | object := self new. max := self instSize. + anArray withIndexDo: [:each :index | - anArray doWithIndex: [:each :index | index > max ifFalse: [object instVarAt: index put: each]]. ^ object! Item was changed: ----- Method: Object>>copySameFrom: (in category 'copying') ----- copySameFrom: otherObject "Copy to myself all instance variables named the same in otherObject. This ignores otherObject's control over its own inst vars." | myInstVars otherInstVars | myInstVars := self class allInstVarNames. otherInstVars := otherObject class allInstVarNames. + myInstVars withIndexDo: [:each :index | - myInstVars doWithIndex: [:each :index | | match | (match := otherInstVars indexOf: each) > 0 ifTrue: [self instVarAt: index put: (otherObject instVarAt: match)]]. 1 to: (self basicSize min: otherObject basicSize) do: [:i | self basicAt: i put: (otherObject basicAt: i)]. ! Item was changed: ----- Method: Object>>longPrintOn: (in category 'printing') ----- longPrintOn: aStream "Append to the argument, aStream, the names and values of all of the receiver's instance variables." + self class allInstVarNames withIndexDo: - self class allInstVarNames doWithIndex: [:title :index | aStream nextPutAll: title; nextPut: $:; space; tab; print: (self instVarAt: index); cr]! Item was changed: ----- Method: Object>>longPrintOn:limitedTo:indent: (in category 'printing') ----- longPrintOn: aStream limitedTo: sizeLimit indent: indent "Append to the argument, aStream, the names and values of all of the receiver's instance variables. Limit is the length limit for each inst var." + self class allInstVarNames withIndexDo: - self class allInstVarNames doWithIndex: [:title :index | indent timesRepeat: [aStream tab]. aStream nextPutAll: title; nextPut: $:; space; tab; nextPutAll: ((self instVarAt: index) printStringLimitedTo: (sizeLimit -3 -title size max: 1)); cr]! From commits at source.squeak.org Thu Aug 20 12:38:30 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 12:38:30 0000 Subject: [squeak-dev] The Inbox: Monticello-ct.727.mcz Message-ID: A new version of Monticello was added to project The Inbox: http://source.squeak.org/inbox/Monticello-ct.727.mcz ==================== Summary ==================== Name: Monticello-ct.727 Author: ct Time: 20 August 2020, 2:38:27.66964 pm UUID: b81a07b6-cb93-6f48-847e-dbe86460d69f Ancestors: Monticello-cmm.726 Complements 60Deprecated-ct.80 (deprecation #doWithIndex: & Co.). =============== Diff against Monticello-cmm.726 =============== Item was changed: ----- Method: MCTool>>buildWith: (in category 'toolbuilder') ----- buildWith: builder | windowBuilder | windowBuilder := MCToolWindowBuilder builder: builder tool: self. self widgetSpecs do: [:spec | | send fractions offsets | send := spec first. fractions := (spec at: 2 ifAbsent: [#(0 0 1 1)]) copy. offsets := (spec at: 3 ifAbsent: [#(0 0 0 0)]) copy. + fractions withIndexDo: [:numberOrSymbol :index | - fractions doWithIndex: [:numberOrSymbol :index | numberOrSymbol isSymbol ifTrue: [fractions at: index put: (self perform: numberOrSymbol)]]. + offsets withIndexDo: [:numberOrSymbol :index | - offsets doWithIndex: [:numberOrSymbol :index | numberOrSymbol isSymbol ifTrue: [offsets at: index put: (self perform: numberOrSymbol)]]. windowBuilder frame: (LayoutFrame fractions: (fractions first @ fractions second corner: fractions third @ fractions fourth) offsets: (offsets first @ offsets second corner: offsets third @ offsets fourth)). windowBuilder perform: send first withArguments: send allButFirst]. ^ windowBuilder build ! From marcel.taeumel at hpi.de Thu Aug 20 12:39:58 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 20 Aug 2020 14:39:58 +0200 Subject: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz In-Reply-To: References: Message-ID: ... just why? Best, Marcel Am 20.08.2020 14:33:41 schrieb commits at source.squeak.org : A new version of 60Deprecated was added to project The Inbox: http://source.squeak.org/inbox/60Deprecated-ct.80.mcz ==================== Summary ==================== Name: 60Deprecated-ct.80 Author: ct Time: 20 August 2020, 2:33:32.63864 pm UUID: 1295269c-62ee-5c45-9315-e66ff5eef57a Ancestors: 60Deprecated-mt.79 Finnaly deprecate #doWithIndex: and #collectWithIndex:. Other packages will be patched right now. =============== Diff against 60Deprecated-mt.79 =============== Item was added: + ----- Method: HashedCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- + doWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexDo: instead'. + ^ self withIndexDo: elementAndIndexBlock! Item was added: + ----- Method: SequenceableCollection>>collectWithIndex: (in category '*60Deprecated-enumerating') ----- + collectWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexCollect: instead'. + ^ self withIndexCollect: elementAndIndexBlock! Item was added: + ----- Method: SequenceableCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- + doWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexDo: instead'. + ^ self withIndexDo: elementAndIndexBlock! Item was changed: ----- Method: StandardFileMenu>>menuSelectionsArray: (in category 'menu building') ----- menuSelectionsArray: aDirectory "Answer a menu selections object corresponding to aDirectory. The object is an array corresponding to each item, each element itself constituting a two-element array, the first element of which contains a selector to operate on and the second element of which contains the parameters for that selector." |dirSize| dirSize := aDirectory pathParts size. ^Array streamContents: [:s | canTypeFileName ifTrue: [s nextPut: (StandardFileMenuResult directory: aDirectory name: nil)]. s nextPut: (StandardFileMenuResult directory: (FileDirectory root) name: ''). + aDirectory pathParts withIndexDo: - aDirectory pathParts doWithIndex: [:d :i | s nextPut: (StandardFileMenuResult directory: (self advance: dirSize - i containingDirectoriesFrom: aDirectory) name: '')]. aDirectory directoryNames do: [:dn | s nextPut: (StandardFileMenuResult directory: (FileDirectory on: (aDirectory fullNameFor: dn)) name: '')]. aDirectory fileNames do: [:fn | pattern do: [:pat | (pat match: fn) ifTrue: [ s nextPut: (StandardFileMenuResult directory: aDirectory name: fn)]]]]! Item was changed: ----- Method: StandardFileMenu>>pathPartsString: (in category 'menu building') ----- pathPartsString: aDirectory "Answer a string concatenating the path parts strings in aDirectory, each string followed by a cr." ^String streamContents: [:s | s nextPutAll: '[]'; cr. + aDirectory pathParts asArray withIndexDo: - aDirectory pathParts asArray doWithIndex: [:part :i | s next: i put: $ . s nextPutAll: part withBlanksTrimmed; cr]]! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Thu Aug 20 12:52:24 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Thu, 20 Aug 2020 12:52:24 +0000 Subject: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz In-Reply-To: References: , Message-ID: Sorry for the overhasty commit storm. From what the old method comment in SequenceableCollection >> #doWithIndex: stated, I believed that the formal deprecation of this selector was already decided but never realized: "Use the new version with consistent naming" In my image, #doWithIndex: has 89 senders opposed to #withIndexDo: which has 156 senders. #doWithIndex: could be a confusing name because usually, the latest phrase before the argument specifies the role or type of the argument, but in this case, the argument is not an index, but a block. Marcel said #withIndexDo: could be considered as confusing either because its name would not match the arguments in the expected block. However, I think it still matches the order because the element is already represented by the receiver of the MessageSend: classes withIndexDo: [:class :index | ...] Open to hear your opinions! However we decide, I think it would improve the overall Smalltalk experience to have a single preferred name for protocols like this one to clean up the things. Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 20. August 2020 14:39:58 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz ... just why? Best, Marcel Am 20.08.2020 14:33:41 schrieb commits at source.squeak.org : A new version of 60Deprecated was added to project The Inbox: http://source.squeak.org/inbox/60Deprecated-ct.80.mcz ==================== Summary ==================== Name: 60Deprecated-ct.80 Author: ct Time: 20 August 2020, 2:33:32.63864 pm UUID: 1295269c-62ee-5c45-9315-e66ff5eef57a Ancestors: 60Deprecated-mt.79 Finnaly deprecate #doWithIndex: and #collectWithIndex:. Other packages will be patched right now. =============== Diff against 60Deprecated-mt.79 =============== Item was added: + ----- Method: HashedCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- + doWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexDo: instead'. + ^ self withIndexDo: elementAndIndexBlock! Item was added: + ----- Method: SequenceableCollection>>collectWithIndex: (in category '*60Deprecated-enumerating') ----- + collectWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexCollect: instead'. + ^ self withIndexCollect: elementAndIndexBlock! Item was added: + ----- Method: SequenceableCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- + doWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexDo: instead'. + ^ self withIndexDo: elementAndIndexBlock! Item was changed: ----- Method: StandardFileMenu>>menuSelectionsArray: (in category 'menu building') ----- menuSelectionsArray: aDirectory "Answer a menu selections object corresponding to aDirectory. The object is an array corresponding to each item, each element itself constituting a two-element array, the first element of which contains a selector to operate on and the second element of which contains the parameters for that selector." |dirSize| dirSize := aDirectory pathParts size. ^Array streamContents: [:s | canTypeFileName ifTrue: [s nextPut: (StandardFileMenuResult directory: aDirectory name: nil)]. s nextPut: (StandardFileMenuResult directory: (FileDirectory root) name: ''). + aDirectory pathParts withIndexDo: - aDirectory pathParts doWithIndex: [:d :i | s nextPut: (StandardFileMenuResult directory: (self advance: dirSize - i containingDirectoriesFrom: aDirectory) name: '')]. aDirectory directoryNames do: [:dn | s nextPut: (StandardFileMenuResult directory: (FileDirectory on: (aDirectory fullNameFor: dn)) name: '')]. aDirectory fileNames do: [:fn | pattern do: [:pat | (pat match: fn) ifTrue: [ s nextPut: (StandardFileMenuResult directory: aDirectory name: fn)]]]]! Item was changed: ----- Method: StandardFileMenu>>pathPartsString: (in category 'menu building') ----- pathPartsString: aDirectory "Answer a string concatenating the path parts strings in aDirectory, each string followed by a cr." ^String streamContents: [:s | s nextPutAll: '[]'; cr. + aDirectory pathParts asArray withIndexDo: - aDirectory pathParts asArray doWithIndex: [:part :i | s next: i put: $ . s nextPutAll: part withBlanksTrimmed; cr]]! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel.taeumel at hpi.de Thu Aug 20 12:55:14 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Thu, 20 Aug 2020 14:55:14 +0200 Subject: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz In-Reply-To: References: <,> Message-ID: Thank you for this explanation. Would have made a great commit message ;-) Also thanks for the highlighted example. Never thought of it that way. Makes sense. Best, Marcel Am 20.08.2020 14:52:33 schrieb Thiede, Christoph : Sorry for the overhasty commit storm. From what the old method comment in SequenceableCollection >> #doWithIndex: stated, I believed that the formal deprecation of this selector was already decided but never realized: "Use the new version with consistent naming" In my image, #doWithIndex: has 89 senders opposed to #withIndexDo: which has 156 senders. #doWithIndex: could be a confusing name because usually, the latest phrase before the argument specifies the role or type of the argument, but in this case, the argument is not an index, but a block. Marcel said #withIndexDo: could be considered as confusing either because its name would not match the arguments in the expected block. However, I think it still matches the order because the element is already represented by the receiver of the MessageSend: classes withIndexDo: [:class :index | ...] Open to hear your opinions! However we decide, I think it would improve the overall Smalltalk experience to have a single preferred name for protocols like this one to clean up the things. Best, Christoph Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 20. August 2020 14:39:58 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz   ... just why? Best, Marcel Am 20.08.2020 14:33:41 schrieb commits at source.squeak.org : A new version of 60Deprecated was added to project The Inbox: http://source.squeak.org/inbox/60Deprecated-ct.80.mcz ==================== Summary ==================== Name: 60Deprecated-ct.80 Author: ct Time: 20 August 2020, 2:33:32.63864 pm UUID: 1295269c-62ee-5c45-9315-e66ff5eef57a Ancestors: 60Deprecated-mt.79 Finnaly deprecate #doWithIndex: and #collectWithIndex:. Other packages will be patched right now. =============== Diff against 60Deprecated-mt.79 =============== Item was added: + ----- Method: HashedCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- + doWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexDo: instead'. + ^ self withIndexDo: elementAndIndexBlock! Item was added: + ----- Method: SequenceableCollection>>collectWithIndex: (in category '*60Deprecated-enumerating') ----- + collectWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexCollect: instead'. + ^ self withIndexCollect: elementAndIndexBlock! Item was added: + ----- Method: SequenceableCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- + doWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexDo: instead'. + ^ self withIndexDo: elementAndIndexBlock! Item was changed: ----- Method: StandardFileMenu>>menuSelectionsArray: (in category 'menu building') ----- menuSelectionsArray: aDirectory "Answer a menu selections object corresponding to aDirectory. The object is an array corresponding to each item, each element itself constituting a two-element array, the first element of which contains a selector to operate on and the second element of which contains the parameters for that selector." |dirSize| dirSize := aDirectory pathParts size. ^Array streamContents: [:s | canTypeFileName ifTrue: [s nextPut: (StandardFileMenuResult directory: aDirectory name: nil)]. s nextPut: (StandardFileMenuResult directory: (FileDirectory root) name: ''). + aDirectory pathParts withIndexDo: - aDirectory pathParts doWithIndex: [:d :i | s nextPut: (StandardFileMenuResult directory: (self advance: dirSize - i containingDirectoriesFrom: aDirectory) name: '')]. aDirectory directoryNames do: [:dn | s nextPut: (StandardFileMenuResult directory: (FileDirectory on: (aDirectory fullNameFor: dn)) name: '')]. aDirectory fileNames do: [:fn | pattern do: [:pat | (pat match: fn) ifTrue: [ s nextPut: (StandardFileMenuResult directory: aDirectory name: fn)]]]]! Item was changed: ----- Method: StandardFileMenu>>pathPartsString: (in category 'menu building') ----- pathPartsString: aDirectory "Answer a string concatenating the path parts strings in aDirectory, each string followed by a cr." ^String streamContents: [:s | s nextPutAll: '[]'; cr. + aDirectory pathParts asArray withIndexDo: - aDirectory pathParts asArray doWithIndex: [:part :i | s next: i put: $ . s nextPutAll: part withBlanksTrimmed; cr]]! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Thu Aug 20 13:06:53 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Thu, 20 Aug 2020 13:06:53 +0000 Subject: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz In-Reply-To: References: <,> , Message-ID: I have stopped to commit the patches to all affected packages, which was a terrible idea as I recognize now. In case we can agree on deprecating #doWithIndex:, I am attaching the corresponding changeset. FWIW, here is the snippet I used to rename all senders of the deprecated selectors: oldSelector := #collectWithIndex:. newSelector := #withIndexCollect:. methods := self systemNavigation allCallsOn: oldSelector. methods do: [:method | method actualClass compile: (method sourceCode copyReplaceTokens: oldSelector with: newSelector) ] displayingProgress: ('Replacing {1} with {2}' format: {oldSelector. newSelector}) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 20. August 2020 14:55:14 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz Thank you for this explanation. Would have made a great commit message ;-) Also thanks for the highlighted example. Never thought of it that way. Makes sense. Best, Marcel Am 20.08.2020 14:52:33 schrieb Thiede, Christoph : Sorry for the overhasty commit storm. From what the old method comment in SequenceableCollection >> #doWithIndex: stated, I believed that the formal deprecation of this selector was already decided but never realized: "Use the new version with consistent naming" In my image, #doWithIndex: has 89 senders opposed to #withIndexDo: which has 156 senders. #doWithIndex: could be a confusing name because usually, the latest phrase before the argument specifies the role or type of the argument, but in this case, the argument is not an index, but a block. Marcel said #withIndexDo: could be considered as confusing either because its name would not match the arguments in the expected block. However, I think it still matches the order because the element is already represented by the receiver of the MessageSend: classes withIndexDo: [:class :index | ...] Open to hear your opinions! However we decide, I think it would improve the overall Smalltalk experience to have a single preferred name for protocols like this one to clean up the things. Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Taeumel, Marcel Gesendet: Donnerstag, 20. August 2020 14:39:58 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz ... just why? Best, Marcel Am 20.08.2020 14:33:41 schrieb commits at source.squeak.org : A new version of 60Deprecated was added to project The Inbox: http://source.squeak.org/inbox/60Deprecated-ct.80.mcz ==================== Summary ==================== Name: 60Deprecated-ct.80 Author: ct Time: 20 August 2020, 2:33:32.63864 pm UUID: 1295269c-62ee-5c45-9315-e66ff5eef57a Ancestors: 60Deprecated-mt.79 Finnaly deprecate #doWithIndex: and #collectWithIndex:. Other packages will be patched right now. =============== Diff against 60Deprecated-mt.79 =============== Item was added: + ----- Method: HashedCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- + doWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexDo: instead'. + ^ self withIndexDo: elementAndIndexBlock! Item was added: + ----- Method: SequenceableCollection>>collectWithIndex: (in category '*60Deprecated-enumerating') ----- + collectWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexCollect: instead'. + ^ self withIndexCollect: elementAndIndexBlock! Item was added: + ----- Method: SequenceableCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- + doWithIndex: elementAndIndexBlock + + self deprecated: 'Use #withIndexDo: instead'. + ^ self withIndexDo: elementAndIndexBlock! Item was changed: ----- Method: StandardFileMenu>>menuSelectionsArray: (in category 'menu building') ----- menuSelectionsArray: aDirectory "Answer a menu selections object corresponding to aDirectory. The object is an array corresponding to each item, each element itself constituting a two-element array, the first element of which contains a selector to operate on and the second element of which contains the parameters for that selector." |dirSize| dirSize := aDirectory pathParts size. ^Array streamContents: [:s | canTypeFileName ifTrue: [s nextPut: (StandardFileMenuResult directory: aDirectory name: nil)]. s nextPut: (StandardFileMenuResult directory: (FileDirectory root) name: ''). + aDirectory pathParts withIndexDo: - aDirectory pathParts doWithIndex: [:d :i | s nextPut: (StandardFileMenuResult directory: (self advance: dirSize - i containingDirectoriesFrom: aDirectory) name: '')]. aDirectory directoryNames do: [:dn | s nextPut: (StandardFileMenuResult directory: (FileDirectory on: (aDirectory fullNameFor: dn)) name: '')]. aDirectory fileNames do: [:fn | pattern do: [:pat | (pat match: fn) ifTrue: [ s nextPut: (StandardFileMenuResult directory: aDirectory name: fn)]]]]! Item was changed: ----- Method: StandardFileMenu>>pathPartsString: (in category 'menu building') ----- pathPartsString: aDirectory "Answer a string concatenating the path parts strings in aDirectory, each string followed by a cr." ^String streamContents: [:s | s nextPutAll: '[]'; cr. + aDirectory pathParts asArray withIndexDo: - aDirectory pathParts asArray doWithIndex: [:part :i | s next: i put: $ . s nextPutAll: part withBlanksTrimmed; cr]]! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: deprecate #doWithIndex#.1.cs URL: From leves at caesar.elte.hu Thu Aug 20 14:07:33 2020 From: leves at caesar.elte.hu (Levente Uzonyi) Date: Thu, 20 Aug 2020 16:07:33 +0200 (CEST) Subject: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz In-Reply-To: References: <, > , Message-ID: Hi Christoph, +1 from me to deprecate it. Even if the final decision will be to not deprecate/remove those methods, using #withIndex*: instead of #*WithIndex: in Trunk won't hurt. So, feel free to push those changes, as those should be in the Trunk IMO. Levente On Thu, 20 Aug 2020, Thiede, Christoph wrote: > > I have stopped to commit the patches to all affected packages, which was a terrible idea as I recognize now. In case we can agree on deprecating #doWithIndex:, I am attaching the corresponding changeset. > > > FWIW, here is the snippet I used to rename all senders of the deprecated selectors: > > oldSelector := #collectWithIndex:. > newSelector := #withIndexCollect:. > > methods := self systemNavigation allCallsOn: oldSelector. > methods > do: [:method | > method actualClass compile: (method sourceCode > copyReplaceTokens: oldSelector > with: newSelector) ] > displayingProgress: ('Replacing {1} with {2}' format: {oldSelector. newSelector}) > [FORM] > > Best, > Christoph > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: Squeak-dev im Auftrag von Taeumel, Marcel > Gesendet: Donnerstag, 20. August 2020 14:55:14 > An: squeak-dev > Betreff: Re: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz   > Thank you for this explanation. Would have made a great commit message ;-) > Also thanks for the highlighted example. Never thought of it that way. Makes sense. > > Best, > Marcel > > Am 20.08.2020 14:52:33 schrieb Thiede, Christoph : > > Sorry for the overhasty commit storm. From what the old method comment in SequenceableCollection >> #doWithIndex: stated, I believed that the formal deprecation of this selector was already decided but never > realized: > > > "Use the new version with consistent naming" > > > In my image, #doWithIndex: has 89 senders opposed to #withIndexDo: which has 156 senders. #doWithIndex: could be a confusing name because usually, the latest phrase before the argument specifies the role or type > of the argument, but in this case, the argument is not an index, but a block. > > > Marcel said #withIndexDo: could be considered as confusing either because its name would not match the arguments in the expected block. However, I think it still matches the order because the element is already > represented by the receiver of the MessageSend: > > > classes withIndexDo: [:class :index | ...] > > > Open to hear your opinions! However we decide, I think it would improve the overall Smalltalk experience to have a single preferred name for protocols like this one to clean up the things. > > > Best, > > Christoph > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: Squeak-dev im Auftrag von Taeumel, Marcel > Gesendet: Donnerstag, 20. August 2020 14:39:58 > An: squeak-dev > Betreff: Re: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz   > ... just why? > Best, > Marcel > > Am 20.08.2020 14:33:41 schrieb commits at source.squeak.org : > > A new version of 60Deprecated was added to project The Inbox: > http://source.squeak.org/inbox/60Deprecated-ct.80.mcz > > ==================== Summary ==================== > > Name: 60Deprecated-ct.80 > Author: ct > Time: 20 August 2020, 2:33:32.63864 pm > UUID: 1295269c-62ee-5c45-9315-e66ff5eef57a > Ancestors: 60Deprecated-mt.79 > > Finnaly deprecate #doWithIndex: and #collectWithIndex:. Other packages will be patched right now. > > =============== Diff against 60Deprecated-mt.79 =============== > > Item was added: > + ----- Method: HashedCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- > + doWithIndex: elementAndIndexBlock > + > + self deprecated: 'Use #withIndexDo: instead'. > + ^ self withIndexDo: elementAndIndexBlock! > > Item was added: > + ----- Method: SequenceableCollection>>collectWithIndex: (in category '*60Deprecated-enumerating') ----- > + collectWithIndex: elementAndIndexBlock > + > + self deprecated: 'Use #withIndexCollect: instead'. > + ^ self withIndexCollect: elementAndIndexBlock! > > Item was added: > + ----- Method: SequenceableCollection>>doWithIndex: (in category '*60Deprecated-enumerating') ----- > + doWithIndex: elementAndIndexBlock > + > + self deprecated: 'Use #withIndexDo: instead'. > + ^ self withIndexDo: elementAndIndexBlock! > > Item was changed: > ----- Method: StandardFileMenu>>menuSelectionsArray: (in category 'menu building') ----- > menuSelectionsArray: aDirectory > "Answer a menu selections object corresponding to aDirectory. The object is an array corresponding to each item, each element itself constituting a two-element array, the first element of which contains a > selector to operate on and the second element of which contains the parameters for that selector." > > |dirSize| > dirSize := aDirectory pathParts size. > ^Array streamContents: [:s | > canTypeFileName ifTrue: > [s nextPut: (StandardFileMenuResult > directory: aDirectory > name: nil)]. > s nextPut: (StandardFileMenuResult > directory: (FileDirectory root) > name: ''). > + aDirectory pathParts withIndexDo: > - aDirectory pathParts doWithIndex: > [:d :i | s nextPut: (StandardFileMenuResult > directory: (self > advance: dirSize - i > containingDirectoriesFrom: aDirectory) > name: '')]. > aDirectory directoryNames do: > [:dn | s nextPut: (StandardFileMenuResult > directory: (FileDirectory on: (aDirectory fullNameFor: dn)) > name: '')]. > aDirectory fileNames do: > [:fn | pattern do: [:pat | (pat match: fn) ifTrue: [ > s nextPut: (StandardFileMenuResult > directory: aDirectory > name: fn)]]]]! > > Item was changed: > ----- Method: StandardFileMenu>>pathPartsString: (in category 'menu building') ----- > pathPartsString: aDirectory > "Answer a string concatenating the path parts strings in aDirectory, each string followed by a cr." > > ^String streamContents: > [:s | > s nextPutAll: '[]'; cr. > + aDirectory pathParts asArray withIndexDo: > - aDirectory pathParts asArray doWithIndex: > [:part :i | > s next: i put: $ . > s nextPutAll: part withBlanksTrimmed; cr]]! > > > > From lewis at mail.msen.com Thu Aug 20 16:06:18 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Thu, 20 Aug 2020 12:06:18 -0400 Subject: [squeak-dev] Trying to help to bring BabySRE to modern Squeak In-Reply-To: References: Message-ID: <20200820160618.GA12669@shell.msen.com> Edgar, On Thu, Aug 20, 2020 at 08:08:16AM -0300, Edgar J. De Cleene wrote: > Finally I get BabySRE working in 6.0, without freezes and without undeclared > classes. > This do not means all wonderful work of Trygve is on 6.0 > But is a start. > Also I see a couple of pages is on swiki > Still have my own expanded view on 190.191.74.232:9090 user visita no pass > Load orden is TextMorphEditor from Jurasik Park era Bravo!!! Well done!!! Dave > > from Ladrillos repo > BabySRE-Connectors > BB1IDE-Support-edc.1 > BB1UnmappedRole > And finally > BabySRE-edc.51 > > Also found I make several .mcz coming of original 3.10 image , so I dig some > more and perhaps we have more of Trygve . > > So no Hasta la vista Baby. > Say Volviste Baby (You come back Baby) > > > Edgar > @morplenauta > From commits at source.squeak.org Thu Aug 20 16:38:31 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 16:38:31 0000 Subject: [squeak-dev] The Inbox: Morphic-ct.1675.mcz Message-ID: A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1675.mcz ==================== Summary ==================== Name: Morphic-ct.1675 Author: ct Time: 20 August 2020, 6:38:23.443941 pm UUID: b76420e2-369c-7547-89c9-e553ffc4aa7c Ancestors: Morphic-mt.1674 Proposal to fix unreliable text dragging into text morphs as described in http://forum.world.st/BUG-Text-drag-and-drop-to-workspace-unreliable-td5109035.html =============== Diff against Morphic-mt.1674 =============== Item was added: + ----- Method: PluggableTextMorph>>handleDropMorph: (in category 'dropping/grabbing') ----- + handleDropMorph: anEvent + + "Give TextMorphForEditView another chance to handle the drop. It did not get any chance before if it is smaller than ourselves." + textMorph handleDropMorph: anEvent. + + "If the event has been handled now, super will ignore it." + ^ super handleDropMorph: anEvent! From Christoph.Thiede at student.hpi.uni-potsdam.de Thu Aug 20 16:39:14 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Thu, 20 Aug 2020 16:39:14 +0000 Subject: [squeak-dev] [BUG] Text drag and drop to workspace unreliable In-Reply-To: References: Message-ID: <2d1990eb9515419589eb10e97d48c105@student.hpi.uni-potsdam.de> Hi Jakob, does Morphic-ct.1675 resolve the issue for you? :-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Sonntag, 29. Dezember 2019 21:40:19 An: squeak-dev at lists.squeakfoundation.org Betreff: [squeak-dev] [BUG] Text drag and drop to workspace unreliable Hi, I just noticed that the newly introduced text drag and drop sometimes does not work when dragging text between workspaces. It has always worked until today so I suspect the culprit is among the more recent changes. Problem: When dragging the selected text from one workspace to another, sometimes an object reference is copied to the bindings of the workspace instead of pasting the text. In the target text, the newly created variable name appears instead (e. g. text3997962) as if I had dropped another non-text object. At least the text is not removed from the source workspace when this happens... Problem #2: It does not always happen. When dragging from a third workspace it suddenly worked and then also from the second again. Then I reset my texts back to the old state and now it is broken again. Expected behavior: The selected text from the source workspace is cut from there, and pasted at the drop hand location in the target workspace. Currently I have three workspaces #1, #2, #3. If I drag the selection from #1 to #2, it works. If I drag from #1 to #3 it does not. Dragging from #2 to #3 does not work. Dragging from #2 to #1 does work. Now dragging from #1 to #3 suddenly does work... I dragged to the start of the text this time. Dragging back from #3 to #1 works. Dragging from #1 to #3 to the end of it also works. Dragging back from #1 to #3. Resetting (Cmd+l, lowercase L) text of #3. Dragging from #1 to the end of #3 does not work again. Variable pasted at the start of the text. Repeated dragging of the same text from #1 to #3 always pastes the variable. Dragging to the middle of #3 works! Dragging the pasted text inside of #3 to the end removed the text and pasted a variable instead. Hypothesis: it does not work to drop the text beyond the TextMorphForEditView. And so far I might just have been lucky to always have enough blank lines at the end of my target workspace. Workspaces #1 and #2 from above contain much more text than #3 and fill the whole editing area of the workspace, so this would be consistent. Squeak5.3beta latest update: #19300 Kind regards, Jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Thu Aug 20 16:44:06 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 16:44:06 0000 Subject: [squeak-dev] The Inbox: Morphic-ct.1676.mcz Message-ID: A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1676.mcz ==================== Summary ==================== Name: Morphic-ct.1676 Author: ct Time: 20 August 2020, 6:44:00.047941 pm UUID: e6ef1618-7b58-634f-aa9c-6fc14583d426 Ancestors: Morphic-mt.1674 Fix missing invalidation when dragging text from one pluggable text morph into another one To reproduce: Open two workspaces A and B, type "foo" into A and "bar" into B, and drag the "foo" just behind the "bar". Before this commit, "foo" was still displayed in A - until you tried to select it. =============== Diff against Morphic-mt.1674 =============== Item was changed: ----- Method: TextMorphForEditView>>acceptDroppingMorph:event: (in category 'dropping/grabbing') ----- acceptDroppingMorph: aTransferMorph event: evt "Accept a text to be inserted at the event/cursor position. Either remove or keep the source text depending on the transfer morph's copy state." | sourceEditor | sourceEditor := (aTransferMorph source respondsTo: #editor) ifTrue: [aTransferMorph source editor] ifFalse: [nil]. self handleInteraction: [ "1) Delete selection if it is a move operation." (aTransferMorph shouldCopy or: [sourceEditor isNil]) ifFalse: [ + sourceEditor morph handleEdit: [ + sourceEditor destructiveBackWord. + sourceEditor history previous isCompositeRedo: sourceEditor == self editor]]. - sourceEditor destructiveBackWord. - sourceEditor history previous isCompositeRedo: sourceEditor == self editor]. "2) Insert selection at new place." self editor addText: aTransferMorph passenger asText event: evt. self editor history previous isCompositeUndo: (sourceEditor == self editor and: [aTransferMorph shouldCopy not])] fromEvent: evt. evt hand newKeyboardFocus: self.! From commits at source.squeak.org Thu Aug 20 18:39:44 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 20 Aug 2020 18:39:44 0000 Subject: [squeak-dev] The Trunk: Network-eem.241.mcz Message-ID: Eliot Miranda uploaded a new version of Network to project The Trunk: http://source.squeak.org/trunk/Network-eem.241.mcz ==================== Summary ==================== Name: Network-eem.241 Author: eem Time: 20 August 2020, 11:39:42.945514 am UUID: ec190e68-dd59-42c7-9b6a-5afd53adc703 Ancestors: Network-dtl.240 Add a primitive error code to primSocketReceiveDataAvailable:/primitiveSocketReceiveDataAvailable to attempt to shed light on persistent primitive failures when runing unit tests on MacOS. =============== Diff against Network-dtl.240 =============== Item was changed: ----- Method: Socket>>primSocketReceiveDataAvailable: (in category 'primitives') ----- primSocketReceiveDataAvailable: socketID + "Answer if data may be available for reading from the current socket." - "Return true if data may be available for reading from the current socket." + - self primitiveFailed ! From LEnglish5 at cox.net Thu Aug 20 20:06:11 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Thu, 20 Aug 2020 13:06:11 -0700 Subject: [squeak-dev] Has anyone gotten FFI working on squeak on a Mac lately? In-Reply-To: References: <9252928B-9FE0-4648-8368-9F9F82133E5C@cox.net> <93AF94EB-D3F8-49F9-9CD4-A318CF86536F@gmail.com> <06140EBB-871F-4B72-9996-17E161DC8E80@cox.net> <151DD396-3602-4F88-AB23-57273C3402FC@cox.net> Message-ID: It’s the simplest library I could think of: .h file: #ifndef FFITest_h #define FFITest_h #define PI 3.14159 double GetPi(void); #endif /* FFITest_h */ .c file: #include "FFITest.h" double GetPi(void){return PI;}; . By the way, I managed to get things working just fine in my own build of the Mac 64-bit vm, but some new odd behavior as shown up. I’ll explain in a yet another thread. L > On Aug 20, 2020, at 12:31 AM, Tobias Pape wrote: > > >> On 20.08.2020, at 09:19, LawsonEnglish wrote: >> >> If you look at the FFIPrim bundle, it looks different. >> >> I still can’t get anything to work except those bundles that are included with the all-in-one. >> >> >> L >> >> This is with Cataina. >> >> L > > Can you share the source of your test library? > > best regards > -tobias > >> >>> On Aug 19, 2020, at 12:31 AM, Tobias Pape wrote: >>> >>> Hi >>> >>>> On 16.08.2020, at 09:36, LawsonEnglish wrote: >>>> >>>> Running otool -L on my dylib: >>>> >>>> otool -L otool -L libFFITest.dylib >>>> libFFITest.dylib: >>>> /libFFITest.dylib (compatibility version 1.0.0, current version 1.0.0) >>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) >>>> >>>> however, running it on the executable int eh SqueakFFIPrims.bundle: >>>> >>>> otool -L SqueakFFIPrims >>>> SqueakFFIPrims: >>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2) >>>> >>>> >>>> I’m not sure what the difference means. I can sorta remove /libFFITest.dylib but the "(compatibility version 1.0.0, current version 1.0.0)” remains, and I still get the same error whether or not /libFFITest.dylib is present. >>>> >>>> >>> >>> there's a stark difference, sadly. >>> The Plugins, which are bundles on macOS, are _not_ simply dynamic libs: >>> >>> >>> [Squeak.app/Contents/Resources]$ otool -L CameraPlugin.bundle/Contents/MacOS/CameraPlugin >>> CameraPlugin.bundle/Contents/MacOS/CameraPlugin: >>> /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation (compatibility version 1.0.0, current version 2.0.0) >>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1450.15.0) >>> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1129.5.0) >>> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1450.15.0) >>> /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0) >>> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0) >>> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) >>> >>> [Squeak.app/Contents/Resources]$ file CameraPlugin.bundle/Contents/MacOS/CameraPlugin >>> CameraPlugin.bundle/Contents/MacOS/CameraPlugin: Mach-O 64-bit bundle x86_64 >>> >>> Dynamic libs look differently: >>> >>> [~]$ otool -L /usr/lib/libbz2.dylib >>> /usr/lib/libbz2.dylib: >>> /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2) >>> >>> [~]$ file /usr/lib/libbz2.dylib >>> /usr/lib/libbz2.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [i386:Mach-O dynamically linked shared library i386] >>> /usr/lib/libbz2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 >>> /usr/lib/libbz2.dylib (for architecture i386): Mach-O dynamically linked shared library i386 >>> >>> =-=-= >>> >>> I would suggest you first try to call a known function in a known library. For example: >>> >>> const char* BZ2_bzlibVersion(void); from libbzip2. >>> >>> >>> =-=-= >>> >>> Other than that, I can't help without some artifact to look at, sorry :/ >>> >>> Best regards >>> -Tobias >>> >>> >>> >>>> >>>> Can you give me a hint as to what the output from otool -L should look like for a dylib that is useable from within /Resources? >>>> >>>> L >>>> >>>> >>>>> On Aug 14, 2020, at 9:19 PM, Eliot Miranda wrote: >>>>> >>>>> Hi Lawson, >>>>> >>>>>> On Aug 14, 2020, at 6:21 PM, LawsonEnglish wrote: >>>>>> >>>>>> I’m not saying it isn’t stable. >>>>> >>>>> I know. I was just saying I don’t think anything has been broken recently, so the issue is not in the FFI per se. >>>>> >>>>>> However, the test functions are in the FFI plugin, which is a .bundle. I’ve been trying to use a .dylib. >>>>> >>>>> There’s a SqueakFFIPlugin dylib (a dylib in all but name) in SqueakFFIPlugin.bundle/Contents/MacOS/SqueakFFIPlugin. That’s what the FFI actually loads. >>>>> >>>>>> I realize that this should. make no difference, and yet, as I said, Craig Latta watched me do the whole thing from scratch via skype screensharing and he didn’t see an error. >>>>>> >>>>>> SO again: has anyone used a non-Squeak distribution/non-bundle with FFI lately? >>>>> >>>>> Yes. >>>>> >>>>>> I tested it on both Catlaina and Mojave and I get teh External module not found error, even with my own .dylib that isn’t hardcoded to sit in a specific directory. >>>>>> >>>>>> WHich leads to a suggestion: if it really is a Mac OS x issue, rather than my own stupidity, it may be necessary to start testing against a library that is merely sitting in the Resource directory, rather than inside a .bundle. >>>>>> >>>>>> WHich is why I’m still asking: has anyone used their own library (outside a .bundle) with FFI lately on Mac OS X, Catalina OR Mojave? >>>>> >>>>> Yes, and it is extremely tricky. I’ve been using libav and libffmpeg and others. I’ve found one has to examine carefully the output of otool -L and use install_name_tool to change the hard-coded paths of any other non-system Dublin’s a Bykov depends on and make sure one understands and uses @rpath. If your dylib uses any other dylib you’re going to have to do the same exploration. >>>>> >>>>>> >>>>>> I’m still trying to figure out how to PUT a library into a .bundle, or I’d test my theory. >>>>> >>>>> Look at the vm build makefiles for macos; they do this and they can be configured to generate dylibs in a directory, etc. >>>>> >>>>> So first question, what’s the output of >>>>> otool -L mylib >>>>> >>>>> (You can omit all the /System/Library ones) >>>>> >>>>>> L >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From LEnglish5 at cox.net Thu Aug 20 20:55:56 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Thu, 20 Aug 2020 13:55:56 -0700 Subject: [squeak-dev] Got FFI working on my own builds (production and debug) but downloaded all-in-one always never works Message-ID: <756E4228-4A03-46EF-8D55-AA9BFD6D56A8@cox.net> So, with Craig Latta’s help, I managed to build my own vm. I added back in the 5.3-19435 image and changes files, and sources file, and changed the plist appropriately and it works just fine. Yay! However, I never did get the distributed version to work. I can sorta make it work with enough swapping of files, but it eventually crashes on startup even though FFI to my own dylib is working. The unmodified distributed 5.3 all-in-work apparently ALWAYS eventually crashes onstartup after trying to load a dylib and then staving, if I do it enough times, but thus far the ones I built do not do this. I can continue with my FFI experiments now (thanks everyone for their help), but unless something is very wrong with my Mac’s setup, the latst vesion of catalina isn’t stable for FFI via dylib. L From craig at blackpagedigital.com Thu Aug 20 21:00:53 2020 From: craig at blackpagedigital.com (Craig Latta) Date: Thu, 20 Aug 2020 14:00:53 -0700 Subject: [squeak-dev] Trying to help to bring BabySRE to modern Squeak In-Reply-To: References: Message-ID: Sweet! -C *** On 20/8/20 04:08, Edgar J. De Cleene wrote: > Finally I get BabySRE working in 6.0, without freezes and without undeclared > classes. > This do not means all wonderful work of Trygve is on 6.0 > But is a start. > Also I see a couple of pages is on swiki > Still have my own expanded view on 190.191.74.232:9090 user visita no pass > Load orden is TextMorphEditor from Jurasik Park era > > from Ladrillos repo > BabySRE-Connectors > BB1IDE-Support-edc.1 > BB1UnmappedRole > And finally > BabySRE-edc.51 > > Also found I make several .mcz coming of original 3.10 image , so I dig some > more and perhaps we have more of Trygve . > > So no Hasta la vista Baby. > Say Volviste Baby (You come back Baby) > > > Edgar > @morplenauta -- Craig Latta Black Page Digital Berkeley, California blackpagedigital.com From eliot.miranda at gmail.com Fri Aug 21 13:29:12 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 21 Aug 2020 06:29:12 -0700 Subject: [squeak-dev] trunk and new vm etiquette In-Reply-To: References: Message-ID: <67D8ACD9-6C74-46E6-9E84-EEEF9B8EC4D4@gmail.com> Hi Fabio, > On Jul 28, 2020, at 12:10 PM, Fabio Niephaus wrote: > >  >> On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg wrote: > >> Who can update so that new bundles from http://files.squeak.org/trunk/ uses new VM ? > > I can do that, but I wonder whether there should be a new VM release? I haven't fully followed the discussion: are the changes backwards compatible? Always, by policy. Until a major release new VMs are always backwards-compatible. If a particular VM change breaks backward compatibility then then it is a buggy VM unless the old behaviour was suspect/a bug. At a major release, and only at a major release, significant backward compatibility support may be dropped. But the basic idea of the VM, which should be true for most VMs, be they Smalltalk or VMWare, is that they get better, but continue to implement the same machine with no change to existing semantics and functionality. You can see in the progression from V3 VMs to Spur VMs an example of a major change. Lots of backwards compatibility was dropped to allow substantial improvement. You can see Nicolas’ work on X11 events (IIRC) as an example of a minor change that broke some older images which were working around a VM bug with events. We judged it better to fix and clarify the convoluted X11 event handling code rather than continue to support perfect backwards compatibility hete. But in general day-to-day vm changes are bug fixes and enhancements they *do not* break backwards compatibility. If they did this wouldn’t be a production VM but some kind of research vehicle. The OpenSmalltalk-vm attempts very much to be a production vm. Eliot, _,,,^..^,,,_ (phone) > > Fabio > >> >> Best, >> Karl >> >>> On Mon, Jul 27, 2020 at 10:47 AM Marcel Taeumel wrote: >>> Works: >>> >>> >>> Best, >>> Marcel >>>> Am 23.07.2020 13:41:17 schrieb Marcel Taeumel : >>>> >>>> Hmm... AppVeyor is just for the Windows builds. We might want to do a beta release for such crucial fixes and then point to the GitHub releases page? >>>> >>>> Best, >>>> Marcel >>>>> Am 22.07.2020 19:50:31 schrieb Eliot Miranda : >>>>> >>>>> >>>>> >>>>>> On Jul 22, 2020, at 7:44 AM, Marcel Taeumel wrote: >>>>>> >>>>>>  >>>>>> Hi Eliot, >>>>>> >>>>>> looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm". >>>>> >>>>> Should we augment that with a direct pointer to the Appveyor CI server? >>>>> >>>>>> >>>>>> Best, >>>>>> Marcel >>>>>>> Am 22.07.2020 16:41:08 schrieb Eliot Miranda : >>>>>>> >>>>>>>  >>>>>>> >>>>>>>>> On Jul 22, 2020, at 12:49 AM, Marcel Taeumel wrote: >>>>>>>>> >>>>>>>>  >>>>>>>> Hi Levente. >>>>>>>> >>>>>>>> > I'm thinking about checking the VM version in the preamble of the package >>>>>>>> > and raising a Warning when it clearly lacks the required updates. >>>>>>>> > Users can still continute with a Warning or terminate the update process, >>>>>>>> > while cli tools will act as if an error had occured. >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> A one-liner would be nice. The warning should also (roughly) point to the location of the new VM for download. >>>>>>>> >>>>>>>> MCMcmUpdater checkVM: 202003021730. "and newer" >>>>>>> >>>>>>> I wrote it like this: >>>>>>> >>>>>>> "Use of the Spur FloatArray>>at:[put:] prims requires at least VMMaker.oscog.2778" >>>>>>> >>>>>>> Smalltalk vmVMMakerVersion < 2778 ifTrue: >>>>>>> [Warning signal: 'This virtual machine is too old to support correct versions of the FloatArray>>at:[put:] primitives 238 and 239. FloatArray subclasses will not behave correctly and FloatArray[64]Test tests will fail. Please upgrade your VM. You may continue and upgrade later or abort and upgrade now.']! >>>>>>> >>>>>>>> Best, >>>>>>>> Marcel >>>>>>>>> Am 21.07.2020 20:21:39 schrieb Levente Uzonyi : >>>>>>>>> >>>>>>>>> Hi Eliot, >>>>>>>>> >>>>>>>>> On Mon, 20 Jul 2020, Eliot Miranda wrote: >>>>>>>>> >>>>>>>>> > Hi All, >>>>>>>>> > I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put]. The new replacement, which allows two methods >>>>>>>>> > (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods. The issue is when to publish the corrections to trunk. >>>>>>>>> > Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests. However, I do want to push the corrections soon, because they're a >>>>>>>>> > substantial improvement. So the question is how long should I wait? >>>>>>>>> > >>>>>>>>> > Is it OK if I push the fixes to FloatArray and subclasses in a week? Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up? If so, as soon as the AppVeyor builds succeed >>>>>>>>> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM. >>>>>>>>> >>>>>>>>> I think most people don't update their VMs often. I still tend to fire >>>>>>>>> up the one shipped with the 5.3 release. So, IMO the question is not how >>>>>>>>> long to wait but what to do when things are about to break. >>>>>>>>> I presume that without updating the VM, the image would not work properly. >>>>>>>>> So, I think the best would be if the user were warned during the update >>>>>>>>> if the VM would be incompatible with the changes. >>>>>>>>> I'm thinking about checking the VM version in the preamble of the package >>>>>>>>> and raising a Warning when it clearly lacks the required updates. >>>>>>>>> Users can still continute with a Warning or terminate the update process, >>>>>>>>> while cli tools will act as if an error had occured. >>>>>>>>> >>>>>>>>> >>>>>>>>> Levente >>>>>>>>> >>>>>>>>> > _,,,^..^,,,_ >>>>>>>>> > best, Eliot >>>>>>>>> > >>>>>>>>> > >>>>>>>> >>>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at fniephaus.com Fri Aug 21 13:51:28 2020 From: lists at fniephaus.com (Fabio Niephaus) Date: Fri, 21 Aug 2020 15:51:28 +0200 Subject: [squeak-dev] trunk and new vm etiquette In-Reply-To: <67D8ACD9-6C74-46E6-9E84-EEEF9B8EC4D4@gmail.com> References: <67D8ACD9-6C74-46E6-9E84-EEEF9B8EC4D4@gmail.com> Message-ID: On Fri, Aug 21, 2020 at 3:29 PM Eliot Miranda wrote: > > Hi Fabio, > > > On Jul 28, 2020, at 12:10 PM, Fabio Niephaus wrote: > >  > On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg wrote: >> >> Who can update so that new bundles from http://files.squeak.org/trunk/ uses new VM ? > > > I can do that, but I wonder whether there should be a new VM release? I haven't fully followed the discussion: are the changes backwards compatible? > > > Always, by policy. Until a major release new VMs are always backwards-compatible. If a particular VM change breaks backward compatibility then then it is a buggy VM unless the old behaviour was suspect/a bug. At a major release, and only at a major release, significant backward compatibility support may be dropped. The problem is that I have been the one publishing releases, but I don't know whether a release should be marked as major or not. That's why I asked. So I understand this one is a minor fix and I can release the current tip as a new minor release? Fabio > > But the basic idea of the VM, which should be true for most VMs, be they Smalltalk or VMWare, is that they get better, but continue to implement the same machine with no change to existing semantics and functionality. > > You can see in the progression from V3 VMs to Spur VMs an example of a major change. Lots of backwards compatibility was dropped to allow substantial improvement. > > You can see Nicolas’ work on X11 events (IIRC) as an example of a minor change that broke some older images which were working around a VM bug with events. We judged it better to fix and clarify the convoluted X11 event handling code rather than continue to support perfect backwards compatibility hete. > > But in general day-to-day vm changes are bug fixes and enhancements they *do not* break backwards compatibility. If they did this wouldn’t be a production VM but some kind of research vehicle. The OpenSmalltalk-vm attempts very much to be a production vm. > > Eliot, > _,,,^..^,,,_ (phone) > > > Fabio > >> >> Best, >> Karl >> >> On Mon, Jul 27, 2020 at 10:47 AM Marcel Taeumel wrote: >>> >>> Works: >>> >>> >>> Best, >>> Marcel >>> >>> Am 23.07.2020 13:41:17 schrieb Marcel Taeumel : >>> >>> Hmm... AppVeyor is just for the Windows builds. We might want to do a beta release for such crucial fixes and then point to the GitHub releases page? >>> >>> Best, >>> Marcel >>> >>> Am 22.07.2020 19:50:31 schrieb Eliot Miranda : >>> >>> >>> >>> On Jul 22, 2020, at 7:44 AM, Marcel Taeumel wrote: >>> >>>  >>> Hi Eliot, >>> >>> looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm". >>> >>> >>> Should we augment that with a direct pointer to the Appveyor CI server? >>> >>> >>> Best, >>> Marcel >>> >>> Am 22.07.2020 16:41:08 schrieb Eliot Miranda : >>> >>>  >>> >>> On Jul 22, 2020, at 12:49 AM, Marcel Taeumel wrote: >>> >>>  >>> Hi Levente. >>> >>> > I'm thinking about checking the VM version in the preamble of the package >>> > and raising a Warning when it clearly lacks the required updates. >>> > Users can still continute with a Warning or terminate the update process, >>> > while cli tools will act as if an error had occured. >>> >>> +1 >>> >>> A one-liner would be nice. The warning should also (roughly) point to the location of the new VM for download. >>> >>> MCMcmUpdater checkVM: 202003021730. "and newer" >>> >>> >>> I wrote it like this: >>> >>> "Use of the Spur FloatArray>>at:[put:] prims requires at least VMMaker.oscog.2778" >>> >>> Smalltalk vmVMMakerVersion < 2778 ifTrue: >>> [Warning signal: 'This virtual machine is too old to support correct versions of the FloatArray>>at:[put:] primitives 238 and 239. FloatArray subclasses will not behave correctly and FloatArray[64]Test tests will fail. Please upgrade your VM. You may continue and upgrade later or abort and upgrade now.']! >>> >>> Best, >>> Marcel >>> >>> Am 21.07.2020 20:21:39 schrieb Levente Uzonyi : >>> >>> Hi Eliot, >>> >>> On Mon, 20 Jul 2020, Eliot Miranda wrote: >>> >>> > Hi All, >>> > I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put]. The new replacement, which allows two methods >>> > (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods. The issue is when to publish the corrections to trunk. >>> > Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests. However, I do want to push the corrections soon, because they're a >>> > substantial improvement. So the question is how long should I wait? >>> > >>> > Is it OK if I push the fixes to FloatArray and subclasses in a week? Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up? If so, as soon as the AppVeyor builds succeed >>> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM. >>> >>> I think most people don't update their VMs often. I still tend to fire >>> up the one shipped with the 5.3 release. So, IMO the question is not how >>> long to wait but what to do when things are about to break. >>> I presume that without updating the VM, the image would not work properly. >>> So, I think the best would be if the user were warned during the update >>> if the VM would be incompatible with the changes. >>> I'm thinking about checking the VM version in the preamble of the package >>> and raising a Warning when it clearly lacks the required updates. >>> Users can still continute with a Warning or terminate the update process, >>> while cli tools will act as if an error had occured. >>> >>> >>> Levente >>> >>> > _,,,^..^,,,_ >>> > best, Eliot >>> > >>> > >>> >>> >>> >>> >> > > From eliot.miranda at gmail.com Fri Aug 21 15:51:25 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 21 Aug 2020 08:51:25 -0700 Subject: [squeak-dev] trunk and new vm etiquette In-Reply-To: References: Message-ID: <0DC30E93-551D-4AF4-9602-6D0C65B28588@gmail.com> > On Aug 21, 2020, at 6:51 AM, Fabio Niephaus wrote: > > On Fri, Aug 21, 2020 at 3:29 PM Eliot Miranda wrote: >> >> Hi Fabio, >> >> >> On Jul 28, 2020, at 12:10 PM, Fabio Niephaus wrote: >> >>  >>> On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg wrote: >>> >>> Who can update so that new bundles from http://files.squeak.org/trunk/ uses new VM ? >> >> >> I can do that, but I wonder whether there should be a new VM release? I haven't fully followed the discussion: are the changes backwards compatible? >> >> >> Always, by policy. Until a major release new VMs are always backwards-compatible. If a particular VM change breaks backward compatibility then then it is a buggy VM unless the old behaviour was suspect/a bug. At a major release, and only at a major release, significant backward compatibility support may be dropped. > > The problem is that I have been the one publishing releases, but I > don't know whether a release should be marked as major or not. That's > why I asked. So I understand this one is a minor fix and I can release > the current tip as a new minor release? I would want us to use the most recent vm to pass all the tests. In my own work with 3dicc and my own daily work I always use the most up-to-date vm I have available (given that naturally I build my own VMs). But that degree of churn might be unnecessary; often a change is minor, little more than a clean up. If creating and releasing a new bundle can be automated once tests pass then make this the case. Otherwise do what feels comfortable, say once a month. > > Fabio > >> >> But the basic idea of the VM, which should be true for most VMs, be they Smalltalk or VMWare, is that they get better, but continue to implement the same machine with no change to existing semantics and functionality. >> >> You can see in the progression from V3 VMs to Spur VMs an example of a major change. Lots of backwards compatibility was dropped to allow substantial improvement. >> >> You can see Nicolas’ work on X11 events (IIRC) as an example of a minor change that broke some older images which were working around a VM bug with events. We judged it better to fix and clarify the convoluted X11 event handling code rather than continue to support perfect backwards compatibility hete. >> >> But in general day-to-day vm changes are bug fixes and enhancements they *do not* break backwards compatibility. If they did this wouldn’t be a production VM but some kind of research vehicle. The OpenSmalltalk-vm attempts very much to be a production vm. >> >> Eliot, >> _,,,^..^,,,_ (phone) >> >> >> Fabio >> >>> >>> Best, >>> Karl >>> >>> On Mon, Jul 27, 2020 at 10:47 AM Marcel Taeumel wrote: >>>> >>>> Works: >>>> >>>> >>>> Best, >>>> Marcel >>>> >>>> Am 23.07.2020 13:41:17 schrieb Marcel Taeumel : >>>> >>>> Hmm... AppVeyor is just for the Windows builds. We might want to do a beta release for such crucial fixes and then point to the GitHub releases page? >>>> >>>> Best, >>>> Marcel >>>> >>>> Am 22.07.2020 19:50:31 schrieb Eliot Miranda : >>>> >>>> >>>> >>>> On Jul 22, 2020, at 7:44 AM, Marcel Taeumel wrote: >>>> >>>>  >>>> Hi Eliot, >>>> >>>> looks good. In "About Squeak", we point to "Visit https://github.com/OpenSmalltalk/opensmalltalk-vm". >>>> >>>> >>>> Should we augment that with a direct pointer to the Appveyor CI server? >>>> >>>> >>>> Best, >>>> Marcel >>>> >>>> Am 22.07.2020 16:41:08 schrieb Eliot Miranda : >>>> >>>>  >>>> >>>> On Jul 22, 2020, at 12:49 AM, Marcel Taeumel wrote: >>>> >>>>  >>>> Hi Levente. >>>> >>>>> I'm thinking about checking the VM version in the preamble of the package >>>>> and raising a Warning when it clearly lacks the required updates. >>>>> Users can still continute with a Warning or terminate the update process, >>>>> while cli tools will act as if an error had occured. >>>> >>>> +1 >>>> >>>> A one-liner would be nice. The warning should also (roughly) point to the location of the new VM for download. >>>> >>>> MCMcmUpdater checkVM: 202003021730. "and newer" >>>> >>>> >>>> I wrote it like this: >>>> >>>> "Use of the Spur FloatArray>>at:[put:] prims requires at least VMMaker.oscog.2778" >>>> >>>> Smalltalk vmVMMakerVersion < 2778 ifTrue: >>>> [Warning signal: 'This virtual machine is too old to support correct versions of the FloatArray>>at:[put:] primitives 238 and 239. FloatArray subclasses will not behave correctly and FloatArray[64]Test tests will fail. Please upgrade your VM. You may continue and upgrade later or abort and upgrade now.']! >>>> >>>> Best, >>>> Marcel >>>> >>>> Am 21.07.2020 20:21:39 schrieb Levente Uzonyi : >>>> >>>> Hi Eliot, >>>> >>>> On Mon, 20 Jul 2020, Eliot Miranda wrote: >>>> >>>>> Hi All, >>>>> I've just found and fixed a VM bug in an as-yet-unpublished pair of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and Float64ArrayPlugin>>primitiveAt[Put]. The new replacement, which allows two methods >>>>> (at:[put:]) in FloatArray to relace four methods (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times faster than the plugin methods. The issue is when to publish the corrections to trunk. >>>>> Since the existing VM is broken I don't want to simply push to trunk and have people inconvenienced by a sudden emergence of failures in the FoatArrayTests. However, I do want to push the corrections soon, because they're a >>>>> substantial improvement. So the question is how long should I wait? >>>>> >>>>> Is it OK if I push the fixes to FloatArray and subclasses in a week? Do people using trunk keep an eye on the CI builds and upgrade, or would they appreciate a heads up? If so, as soon as the AppVeyor builds succeed >>>>> for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and ask that you upgrade your VM. >>>> >>>> I think most people don't update their VMs often. I still tend to fire >>>> up the one shipped with the 5.3 release. So, IMO the question is not how >>>> long to wait but what to do when things are about to break. >>>> I presume that without updating the VM, the image would not work properly. >>>> So, I think the best would be if the user were warned during the update >>>> if the VM would be incompatible with the changes. >>>> I'm thinking about checking the VM version in the preamble of the package >>>> and raising a Warning when it clearly lacks the required updates. >>>> Users can still continute with a Warning or terminate the update process, >>>> while cli tools will act as if an error had occured. >>>> >>>> >>>> Levente >>>> >>>>> _,,,^..^,,,_ >>>>> best, Eliot >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >> >> > From Christoph.Thiede at student.hpi.uni-potsdam.de Fri Aug 21 17:55:36 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Fri, 21 Aug 2020 17:55:36 +0000 Subject: [squeak-dev] Bug in #copy? Message-ID: Hi all, please consider the following snippet and its output: o := Object new. o addDependent: 42. o copy dependents. "#()" In my opinion, this behavior is misleading for two reasons: 1. #copy is documented as to "answer another instance just like the receiver." From an abstract view of the object, this should include the object's dependents, too. Afaik, DependentsFields is only an implementation detail, but in common sense, the dependents are just another part of the object. 2. If you run exactly the same snippet with a Model instead of an Object (which implements dependencies in a different way under the hood), the copied object will contain the original dependencies, still. I think we should unify this undocumented and unintuitive discrepancy. The Model documentation states it features "fast dependents maintenance" so the behavior should be kept, just optimized. How do you think about this? Can we change the Object behavior or could this introduce any unpredictable consequences? And how could we fix it? And what about #shallowCopy? Unfortunately, it is called directly by more than a hundred senders in the Trunk image. Because DependentsFields is an implementation detail, I wonder whether #shallowCopy should copy the dependents as well. Should we move the actual primitive method to something like #primShallowCopy and in #shallowCopy, update DependentsFields after calling the primitive? Or do we rather consider #shallowCopy as a low-level method (similar to #veryDeepCopyWith: as apposed to #veryDeepCopy) and call it a code smell to call #shallowCopy from a far-away place? And LBNL: What should the following snippet output in your opinion? o1 := Object new. o1 addDependent: 42. o2 := o1 shallowCopy. o1 addDependent: 43. o2 dependents asArray. Should it answer: a) #(), b) #(42), or c) #(42 43)? :D I am looking forward to your opinions! :-) Best, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Fri Aug 21 19:06:07 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 21 Aug 2020 12:06:07 -0700 Subject: [squeak-dev] trunk and new vm etiquette In-Reply-To: References: Message-ID: Hi Fabio, On Jul 28, 2020, at 12:10 PM, Fabio Niephaus wrote:  On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg wrote: > Who can update so that new bundles from http://files.squeak.org/trunk/ > uses new VM ? > I can do that, but I wonder whether there should be a new VM release? I haven't fully followed the discussion: are the changes backwards compatible? Fabio > Best, > Karl > > On Mon, Jul 27, 2020 at 10:47 AM Marcel Taeumel > wrote: > >> Works: >> >> >> Best, >> Marcel >> >> Am 23.07.2020 13:41:17 schrieb Marcel Taeumel : >> Hmm... AppVeyor is just for the Windows builds. We might want to do a >> beta release for such crucial fixes and then point to the GitHub releases >> page? >> >> Best, >> Marcel >> >> Am 22.07.2020 19:50:31 schrieb Eliot Miranda : >> >> >> On Jul 22, 2020, at 7:44 AM, Marcel Taeumel >> wrote: >> >>  >> Hi Eliot, >> >> looks good. In "About Squeak", we point to "Visit >> https://github.com/OpenSmalltalk/opensmalltalk-vm". >> >> >> Should we augment that with a direct pointer to the Appveyor CI server? >> >> >> Best, >> Marcel >> >> Am 22.07.2020 16:41:08 schrieb Eliot Miranda : >>  >> >> On Jul 22, 2020, at 12:49 AM, Marcel Taeumel >> wrote: >> >>  >> Hi Levente. >> >> > I'm thinking about checking the VM version in the preamble of the >> package >> > and raising a Warning when it clearly lacks the required updates. >> > Users can still continute with a Warning or terminate the update >> process, >> > while cli tools will act as if an error had occured. >> >> +1 >> >> A one-liner would be nice. The warning should also (roughly) point to the >> location of the new VM for download. >> >> MCMcmUpdater checkVM: 202003021730. "and newer" >> >> >> I wrote it like this: >> >> "Use of the Spur FloatArray>>at:[put:] prims requires at least >> VMMaker.oscog.2778" >> >> Smalltalk vmVMMakerVersion < 2778 ifTrue: >> [Warning signal: 'This virtual machine is too old to support correct >> versions of the FloatArray>>at:[put:] primitives 238 and 239. FloatArray >> subclasses will not behave correctly and FloatArray[64]Test tests will >> fail. Please upgrade your VM. You may continue and upgrade later or abort >> and upgrade now.']! >> >> Best, >> Marcel >> >> Am 21.07.2020 20:21:39 schrieb Levente Uzonyi : >> Hi Eliot, >> >> On Mon, 20 Jul 2020, Eliot Miranda wrote: >> >> > Hi All, >> > I've just found and fixed a VM bug in an as-yet-unpublished pair of >> primitives that replace FloatArrayPlugin>>primitiveAt[Put] and >> Float64ArrayPlugin>>primitiveAt[Put]. The new replacement, which allows >> two methods >> > (at:[put:]) in FloatArray to relace four methods >> (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times >> faster than the plugin methods. The issue is when to publish the >> corrections to trunk. >> > Since the existing VM is broken I don't want to simply push to trunk >> and have people inconvenienced by a sudden emergence of failures in the >> FoatArrayTests. However, I do want to push the corrections soon, because >> they're a >> > substantial improvement. So the question is how long should I wait? >> > >> > Is it OK if I push the fixes to FloatArray and subclasses in a week? >> Do people using trunk keep an eye on the CI builds and upgrade, or would >> they appreciate a heads up? If so, as soon as the AppVeyor builds succeed >> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and >> ask that you upgrade your VM. >> >> I think most people don't update their VMs often. I still tend to fire >> up the one shipped with the 5.3 release. So, IMO the question is not how >> long to wait but what to do when things are about to break. >> I presume that without updating the VM, the image would not work >> properly. >> So, I think the best would be if the user were warned during the update >> if the VM would be incompatible with the changes. >> I'm thinking about checking the VM version in the preamble of the package >> and raising a Warning when it clearly lacks the required updates. >> Users can still continute with a Warning or terminate the update process, >> while cli tools will act as if an error had occured. >> >> >> Levente >> >> > _,,,^..^,,,_ >> > best, Eliot >> >> _,,,^..^,,,_ (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Fri Aug 21 19:25:56 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 21 Aug 2020 12:25:56 -0700 Subject: [squeak-dev] Bug in #copy? In-Reply-To: References: Message-ID: Hi Christoph, On Fri, Aug 21, 2020 at 10:55 AM Thiede, Christoph < Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > Hi all, > > > please consider the following snippet and its output: > > > o := Object new. > o addDependent: 42. > o copy dependents. "#()" > > > In my opinion, this behavior is misleading for two reasons: > > 1. #copy is documented as to "answer another instance just like the > receiver." From an abstract view of the object, this should include the > object's dependents, too. Afaik, DependentsFields is only an implementation > detail, but in common sense, the dependents are just another part of the > object. > I disagree. Dependents are a mechanism for observing an object. They allow external objects to register interest in a particular instance. Those observers are not interested in observing the state of arbitrary copies, but of particular objects being observed. In the history of Smalltalk-80 that I'm aware of from Smalltalk-80 v2 through to VisualWorks 7.x, copying did *not* copy dependents. In fact, in Model, where for efficiency, Model>>postCopy did self breakDependents. Before we go further, imagine inspecting some object. An inspector updates its view of the object being inspected whenever that object issues a changed method. Now let's inspect a copy of that object. Wth your implementation both inspectors update whenever either object changes state. This isn't at all what we want. Now for the actual bug. If you look at copy for Model in Squeak, copy does *not* break dependents, and hence we get the behaviour you (think you) want: (Model new addDependent: Object new; copy) dependents => a DependentsArray(an Object) This is a bad bug, and I only discovered it when I looked for a counter-example to your suggestion andfound that Model did (IMO) the *wrong* thing. So if there is a bug, and I think there is, the fix is: Model>>postCopy self breakDependents 2. If you run exactly the same snippet with a Model instead of an > Object (which implements dependencies in a different way under the hood), > the copied object will contain the original dependencies, still. I think we > should unify this undocumented and unintuitive discrepancy. The Model > documentation states it features "fast dependents maintenance" so the > behavior should be kept, just optimized. > > > How do you think about this? > > Can we change the Object behavior or could this introduce any > unpredictable consequences? > > And how could we fix it? > > > And what about #shallowCopy? Unfortunately, it is called directly by more > than a hundred senders in the Trunk image. Because DependentsFields is an > implementation detail, I wonder whether #shallowCopy should copy the > dependents as well. Should we move the actual primitive method to > something like #primShallowCopy and in #shallowCopy, update DependentsFields > after calling the primitive? Or do we rather consider #shallowCopy as a > low-level method (similar to #veryDeepCopyWith: as apposed to > #veryDeepCopy) and call it a code smell to call #shallowCopy from a > far-away place? > > > And LBNL: What should the following snippet output in your opinion? > > > o1 := Object new. > o1 addDependent: 42. > o2 := o1 shallowCopy. > o1 addDependent: 43. > o2 dependents asArray. > > > Should it answer: a) #(), b) #(42), or c) #(42 43)? :D > > > I am looking forward to your opinions! :-) > > > Best, > > Christoph > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Fri Aug 21 19:27:20 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 21 Aug 2020 12:27:20 -0700 Subject: [squeak-dev] trunk and new vm etiquette In-Reply-To: References: Message-ID: oops, please ignore... On Fri, Aug 21, 2020 at 12:06 PM Eliot Miranda wrote: > Hi Fabio, > > > On Jul 28, 2020, at 12:10 PM, Fabio Niephaus wrote: > >  > On Tue, 28 Jul 2020 at 8:31 pm, karl ramberg > wrote: > >> Who can update so that new bundles from http://files.squeak.org/trunk/ >> uses new VM ? >> > > I can do that, but I wonder whether there should be a new VM release? I > haven't fully followed the discussion: are the changes backwards compatible? > > Fabio > > >> Best, >> Karl >> >> On Mon, Jul 27, 2020 at 10:47 AM Marcel Taeumel >> wrote: >> >>> Works: >>> >>> >>> Best, >>> Marcel >>> >>> Am 23.07.2020 13:41:17 schrieb Marcel Taeumel : >>> Hmm... AppVeyor is just for the Windows builds. We might want to do a >>> beta release for such crucial fixes and then point to the GitHub releases >>> page? >>> >>> Best, >>> Marcel >>> >>> Am 22.07.2020 19:50:31 schrieb Eliot Miranda : >>> >>> >>> On Jul 22, 2020, at 7:44 AM, Marcel Taeumel >>> wrote: >>> >>>  >>> Hi Eliot, >>> >>> looks good. In "About Squeak", we point to "Visit >>> https://github.com/OpenSmalltalk/opensmalltalk-vm". >>> >>> >>> Should we augment that with a direct pointer to the Appveyor CI server? >>> >>> >>> Best, >>> Marcel >>> >>> Am 22.07.2020 16:41:08 schrieb Eliot Miranda : >>>  >>> >>> On Jul 22, 2020, at 12:49 AM, Marcel Taeumel >>> wrote: >>> >>>  >>> Hi Levente. >>> >>> > I'm thinking about checking the VM version in the preamble of the >>> package >>> > and raising a Warning when it clearly lacks the required updates. >>> > Users can still continute with a Warning or terminate the update >>> process, >>> > while cli tools will act as if an error had occured. >>> >>> +1 >>> >>> A one-liner would be nice. The warning should also (roughly) point to >>> the location of the new VM for download. >>> >>> MCMcmUpdater checkVM: 202003021730. "and newer" >>> >>> >>> I wrote it like this: >>> >>> "Use of the Spur FloatArray>>at:[put:] prims requires at least >>> VMMaker.oscog.2778" >>> >>> Smalltalk vmVMMakerVersion < 2778 ifTrue: >>> [Warning signal: 'This virtual machine is too old to support correct >>> versions of the FloatArray>>at:[put:] primitives 238 and 239. FloatArray >>> subclasses will not behave correctly and FloatArray[64]Test tests will >>> fail. Please upgrade your VM. You may continue and upgrade later or abort >>> and upgrade now.']! >>> >>> Best, >>> Marcel >>> >>> Am 21.07.2020 20:21:39 schrieb Levente Uzonyi : >>> Hi Eliot, >>> >>> On Mon, 20 Jul 2020, Eliot Miranda wrote: >>> >>> > Hi All, >>> > I've just found and fixed a VM bug in an as-yet-unpublished pair >>> of primitives that replace FloatArrayPlugin>>primitiveAt[Put] and >>> Float64ArrayPlugin>>primitiveAt[Put]. The new replacement, which allows >>> two methods >>> > (at:[put:]) in FloatArray to relace four methods >>> (Float32Array>>at:[put:] & Float64Array>>at:[put:]) are some 5 to 10 times >>> faster than the plugin methods. The issue is when to publish the >>> corrections to trunk. >>> > Since the existing VM is broken I don't want to simply push to trunk >>> and have people inconvenienced by a sudden emergence of failures in the >>> FoatArrayTests. However, I do want to push the corrections soon, because >>> they're a >>> > substantial improvement. So the question is how long should I wait? >>> > >>> > Is it OK if I push the fixes to FloatArray and subclasses in a week? >>> Do people using trunk keep an eye on the CI builds and upgrade, or would >>> they appreciate a heads up? If so, as soon as the AppVeyor builds succeed >>> > for CogVM source as per VMMaker.oscog-eem.2778, I'll let you know and >>> ask that you upgrade your VM. >>> >>> I think most people don't update their VMs often. I still tend to fire >>> up the one shipped with the 5.3 release. So, IMO the question is not how >>> long to wait but what to do when things are about to break. >>> I presume that without updating the VM, the image would not work >>> properly. >>> So, I think the best would be if the user were warned during the update >>> if the VM would be incompatible with the changes. >>> I'm thinking about checking the VM version in the preamble of the >>> package >>> and raising a Warning when it clearly lacks the required updates. >>> Users can still continute with a Warning or terminate the update >>> process, >>> while cli tools will act as if an error had occured. >>> >>> >>> Levente >>> >>> > _,,,^..^,,,_ >>> > best, Eliot >>> >>> > _,,,^..^,,,_ (phone) > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Fri Aug 21 19:29:10 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 21 Aug 2020 12:29:10 -0700 Subject: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz In-Reply-To: References: Message-ID: On Thu, Aug 20, 2020 at 7:07 AM Levente Uzonyi wrote: > Hi Christoph, > > +1 from me to deprecate it. > Even if the final decision will be to not deprecate/remove those methods, > using #withIndex*: instead of #*WithIndex: in Trunk won't hurt. > So, feel free to push those changes, as those should be in the Trunk IMO. > +1 > > > Levente > > On Thu, 20 Aug 2020, Thiede, Christoph wrote: > > > > > I have stopped to commit the patches to all affected packages, which was > a terrible idea as I recognize now. In case we can agree on deprecating > #doWithIndex:, I am attaching the corresponding changeset. > > > > > > FWIW, here is the snippet I used to rename all senders of the deprecated > selectors: > > > > oldSelector := #collectWithIndex:. > > newSelector := #withIndexCollect:. > > > > methods := self systemNavigation allCallsOn: oldSelector. > > methods > > do: [:method | > > method actualClass compile: (method sourceCode > > copyReplaceTokens: oldSelector > > with: newSelector) ] > > displayingProgress: ('Replacing {1} with {2}' format: > {oldSelector. newSelector}) > > [FORM] > > > > Best, > > Christoph > > > > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > > Von: Squeak-dev im > Auftrag von Taeumel, Marcel > > Gesendet: Donnerstag, 20. August 2020 14:55:14 > > An: squeak-dev > > Betreff: Re: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz > > Thank you for this explanation. Would have made a great commit message > ;-) > > Also thanks for the highlighted example. Never thought of it that way. > Makes sense. > > > > Best, > > Marcel > > > > Am 20.08.2020 14:52:33 schrieb Thiede, Christoph < > christoph.thiede at student.hpi.uni-potsdam.de>: > > > > Sorry for the overhasty commit storm. From what the old method > comment in SequenceableCollection >> #doWithIndex: stated, I believed that > the formal deprecation of this selector was already decided but never > > realized: > > > > > > "Use the new version with consistent naming" > > > > > > In my image, #doWithIndex: has 89 senders opposed to #withIndexDo: > which has 156 senders. #doWithIndex: could be a confusing name because > usually, the latest phrase before the argument specifies the role or type > > of the argument, but in this case, the argument is not an index, > but a block. > > > > > > Marcel said #withIndexDo: could be considered as confusing either > because its name would not match the arguments in the expected block. > However, I think it still matches the order because the element is already > > represented by the receiver of the MessageSend: > > > > > > classes withIndexDo: [:class :index | ...] > > > > > > Open to hear your opinions! However we decide, I think it would > improve the overall Smalltalk experience to have a single preferred name > for protocols like this one to clean up the things. > > > > > > Best, > > > > Christoph > > > > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > > Von: Squeak-dev im > Auftrag von Taeumel, Marcel > > Gesendet: Donnerstag, 20. August 2020 14:39:58 > > An: squeak-dev > > Betreff: Re: [squeak-dev] The Inbox: 60Deprecated-ct.80.mcz > > ... just why? > > Best, > > Marcel > > > > Am 20.08.2020 14:33:41 schrieb commits at source.squeak.org < > commits at source.squeak.org>: > > > > A new version of 60Deprecated was added to project The Inbox: > > http://source.squeak.org/inbox/60Deprecated-ct.80.mcz > > > > ==================== Summary ==================== > > > > Name: 60Deprecated-ct.80 > > Author: ct > > Time: 20 August 2020, 2:33:32.63864 pm > > UUID: 1295269c-62ee-5c45-9315-e66ff5eef57a > > Ancestors: 60Deprecated-mt.79 > > > > Finnaly deprecate #doWithIndex: and #collectWithIndex:. Other > packages will be patched right now. > > > > =============== Diff against 60Deprecated-mt.79 =============== > > > > Item was added: > > + ----- Method: HashedCollection>>doWithIndex: (in category > '*60Deprecated-enumerating') ----- > > + doWithIndex: elementAndIndexBlock > > + > > + self deprecated: 'Use #withIndexDo: instead'. > > + ^ self withIndexDo: elementAndIndexBlock! > > > > Item was added: > > + ----- Method: SequenceableCollection>>collectWithIndex: (in > category '*60Deprecated-enumerating') ----- > > + collectWithIndex: elementAndIndexBlock > > + > > + self deprecated: 'Use #withIndexCollect: instead'. > > + ^ self withIndexCollect: elementAndIndexBlock! > > > > Item was added: > > + ----- Method: SequenceableCollection>>doWithIndex: (in category > '*60Deprecated-enumerating') ----- > > + doWithIndex: elementAndIndexBlock > > + > > + self deprecated: 'Use #withIndexDo: instead'. > > + ^ self withIndexDo: elementAndIndexBlock! > > > > Item was changed: > > ----- Method: StandardFileMenu>>menuSelectionsArray: (in category > 'menu building') ----- > > menuSelectionsArray: aDirectory > > "Answer a menu selections object corresponding to aDirectory. The > object is an array corresponding to each item, each element itself > constituting a two-element array, the first element of which contains a > > selector to operate on and the second element of which contains > the parameters for that selector." > > > > |dirSize| > > dirSize := aDirectory pathParts size. > > ^Array streamContents: [:s | > > canTypeFileName ifTrue: > > [s nextPut: (StandardFileMenuResult > > directory: aDirectory > > name: nil)]. > > s nextPut: (StandardFileMenuResult > > directory: (FileDirectory root) > > name: ''). > > + aDirectory pathParts withIndexDo: > > - aDirectory pathParts doWithIndex: > > [:d :i | s nextPut: (StandardFileMenuResult > > directory: (self > > advance: dirSize - i > > containingDirectoriesFrom: aDirectory) > > name: '')]. > > aDirectory directoryNames do: > > [:dn | s nextPut: (StandardFileMenuResult > > directory: (FileDirectory on: (aDirectory fullNameFor: dn)) > > name: '')]. > > aDirectory fileNames do: > > [:fn | pattern do: [:pat | (pat match: fn) ifTrue: [ > > s nextPut: (StandardFileMenuResult > > directory: aDirectory > > name: fn)]]]]! > > > > Item was changed: > > ----- Method: StandardFileMenu>>pathPartsString: (in category > 'menu building') ----- > > pathPartsString: aDirectory > > "Answer a string concatenating the path parts strings in > aDirectory, each string followed by a cr." > > > > ^String streamContents: > > [:s | > > s nextPutAll: '[]'; cr. > > + aDirectory pathParts asArray withIndexDo: > > - aDirectory pathParts asArray doWithIndex: > > [:part :i | > > s next: i put: $ . > > s nextPutAll: part withBlanksTrimmed; cr]]! > > > > > > > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From forums.jakob at resfarm.de Fri Aug 21 20:22:53 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Fri, 21 Aug 2020 22:22:53 +0200 Subject: [squeak-dev] Bug in #copy? In-Reply-To: References: Message-ID: My first impression also was that dependents should not observe the new object, be it a Model or anything else. Also Object has some template methods that in the base class do nothing. Since as Object has no state, it makes sense to me that its postCopy method should do nothing. Eliot Miranda schrieb am Fr., 21. Aug. 2020, 21:26: > Hi Christoph, > > On Fri, Aug 21, 2020 at 10:55 AM Thiede, Christoph < > Christoph.Thiede at student.hpi.uni-potsdam.de> wrote: > >> Hi all, >> >> >> please consider the following snippet and its output: >> >> >> o := Object new. >> o addDependent: 42. >> o copy dependents. "#()" >> >> >> In my opinion, this behavior is misleading for two reasons: >> >> 1. #copy is documented as to "answer another instance just like the >> receiver." From an abstract view of the object, this should include the >> object's dependents, too. Afaik, DependentsFields is only an implementation >> detail, but in common sense, the dependents are just another part of the >> object. >> > > I disagree. Dependents are a mechanism for observing an object. They > allow external objects to register interest in a particular instance. > Those observers are not interested in observing the state of arbitrary > copies, but of particular objects being observed. In the history of > Smalltalk-80 that I'm aware of from Smalltalk-80 v2 through to VisualWorks > 7.x, copying did *not* copy dependents. In fact, in Model, where for > efficiency, Model>>postCopy did self breakDependents. > > Before we go further, imagine inspecting some object. An > inspector updates its view of the object being inspected whenever that > object issues a changed method. Now let's inspect a copy of that object. > Wth your implementation both inspectors update whenever either object > changes state. This isn't at all what we want. > > Now for the actual bug. If you look at copy for Model in Squeak, copy > does *not* break dependents, and hence we get the behaviour you (think you) > want: > > > (Model new addDependent: Object new; copy) dependents => a > DependentsArray(an Object) > > This is a bad bug, and I only discovered it when I looked for a > counter-example to your suggestion andfound that Model did (IMO) the > *wrong* thing. So if there is a bug, and I think there is, the fix is: > > Model>>postCopy > self breakDependents > > > 2. If you run exactly the same snippet with a Model instead of an >> Object (which implements dependencies in a different way under the hood), >> the copied object will contain the original dependencies, still. I think we >> should unify this undocumented and unintuitive discrepancy. The Model >> documentation states it features "fast dependents maintenance" so the >> behavior should be kept, just optimized. >> >> >> How do you think about this? >> >> Can we change the Object behavior or could this introduce any >> unpredictable consequences? >> >> And how could we fix it? >> >> >> And what about #shallowCopy? Unfortunately, it is called directly by more >> than a hundred senders in the Trunk image. Because DependentsFields is an >> implementation detail, I wonder whether #shallowCopy should copy the >> dependents as well. Should we move the actual primitive method to >> something like #primShallowCopy and in #shallowCopy, update DependentsFields >> after calling the primitive? Or do we rather consider #shallowCopy as a >> low-level method (similar to #veryDeepCopyWith: as apposed to >> #veryDeepCopy) and call it a code smell to call #shallowCopy from a >> far-away place? >> >> >> And LBNL: What should the following snippet output in your opinion? >> >> >> o1 := Object new. >> o1 addDependent: 42. >> o2 := o1 shallowCopy. >> o1 addDependent: 43. >> o2 dependents asArray. >> >> >> Should it answer: a) #(), b) #(42), or c) #(42 43)? :D >> >> >> I am looking forward to your opinions! :-) >> >> >> Best, >> >> Christoph >> >> > > -- > _,,,^..^,,,_ > best, Eliot > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thepete10 at bellsouth.net Fri Aug 21 22:32:58 2020 From: thepete10 at bellsouth.net (thepete10) Date: Fri, 21 Aug 2020 22:32:58 +0000 (UTC) Subject: [squeak-dev] Bug in #copy? In-Reply-To: References: Message-ID: <1845775198.4317897.1598049178459@mail.yahoo.com> fuck off dickweed On Friday, August 21, 2020, 4:23:16 PM EDT, Jakob Reschke wrote: My first impression also was that dependents should not observe the new object, be it a Model or anything else. Also Object has some template methods that in the base class do nothing. Since as Object has no state, it makes sense to me that its postCopy method should do nothing. Eliot Miranda schrieb am Fr., 21. Aug. 2020, 21:26: Hi Christoph, On Fri, Aug 21, 2020 at 10:55 AM Thiede, Christoph wrote: Hi all, please consider the following snippet and its output: o := Object new. o addDependent: 42. o copy dependents. "#()" In my opinion, this behavior is misleading for two reasons: 1. #copy is documented as to "answer another instance just like the receiver." From an abstract view of the object, this should include the object's dependents, too. Afaik, DependentsFields is only an implementation detail, but in common sense, the dependents are just another part of the object. I disagree.  Dependents are a mechanism for observing an object. They allow external objects to register interest in a particular instance.  Those observers are not interested in observing the state of arbitrary copies, but of particular objects being observed.  In the history of Smalltalk-80 that I'm aware of from Smalltalk-80 v2 through to VisualWorks 7.x, copying did *not* copy dependents.  In fact, in Model, where for efficiency, Model>>postCopy did self breakDependents. Before we go further, imagine inspecting some object.  An inspector updates its view of the object being inspected whenever that object issues a changed method.  Now let's inspect a copy of that object.  Wth your implementation both inspectors update whenever either object changes state.  This isn't at all what we want.   Now for the actual bug.  If you look at copy for Model in Squeak, copy does *not* break dependents, and hence we get the behaviour you (think you) want: (Model new addDependent: Object new; copy) dependents    =>   a DependentsArray(an Object) This is a bad bug, and I only discovered it when I looked for a counter-example to your suggestion andfound that Model did (IMO) the *wrong* thing.  So if there is a bug, and I think there is, the fix is: Model>>postCopy self breakDependents 2. If you run exactly the same snippet with a Model instead of an Object (which implements dependencies in a different way under the hood), the copied object will contain the original dependencies, still. I think we should unify this undocumented and unintuitive discrepancy. The Model documentation states it features "fast dependents maintenance" so the behavior should be kept, just optimized. How do you think about this? Can we change the Object behavior or could this introduce any unpredictable consequences? And how could we fix it? And what about #shallowCopy? Unfortunately, it is called directly by more than a hundred senders in the Trunk image. Because DependentsFields is an implementation detail, I wonder whether #shallowCopy should copy the dependents as well. Should we move the actual primitive method to something like #primShallowCopy and in #shallowCopy, updateDependentsFields after calling the primitive? Or do we rather consider #shallowCopy as a low-level method (similar to #veryDeepCopyWith: as apposed to #veryDeepCopy) and call it a code smell to call #shallowCopy from a far-away place? And LBNL: What should the following snippet output in your opinion? o1 := Object new. o1 addDependent: 42. o2 := o1 shallowCopy. o1 addDependent: 43. o2 dependents asArray. Should it answer: a) #(), b) #(42), or c) #(42 43)? :D I am looking forward to your opinions! :-) Best, Christoph -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Fri Aug 21 23:42:13 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 21 Aug 2020 16:42:13 -0700 Subject: [squeak-dev] Bug in #copy? In-Reply-To: <1845775198.4317897.1598049178459@mail.yahoo.com> References: <1845775198.4317897.1598049178459@mail.yahoo.com> Message-ID: <0FD0B6CF-D705-4C48-8101-8C8CC756A04F@gmail.com> I vote to block this person. _,,,^..^,,,_ (phone) > On Aug 21, 2020, at 3:33 PM, thepete10 wrote: > >  > fuck off dickweed > > On Friday, August 21, 2020, 4:23:16 PM EDT, Jakob Reschke wrote: > > > My first impression also was that dependents should not observe the new object, be it a Model or anything else. > > Also Object has some template methods that in the base class do nothing. Since as Object has no state, it makes sense to me that its postCopy method should do nothing. > > Eliot Miranda schrieb am Fr., 21. Aug. 2020, 21:26: > Hi Christoph, > > On Fri, Aug 21, 2020 at 10:55 AM Thiede, Christoph wrote: > Hi all, > > > > please consider the following snippet and its output: > > > > o := Object new. > o addDependent: 42. > o copy dependents. "#()" > > In my opinion, this behavior is misleading for two reasons: > > 1. #copy is documented as to "answer another instance just like the receiver." From an abstract view of the object, this should include the object's dependents, too. Afaik, DependentsFields is only an implementation detail, but in common sense, the dependents are just another part of the object. > > > I disagree. Dependents are a mechanism for observing an object. They allow external objects to register interest in a particular instance. Those observers are not interested in observing the state of arbitrary copies, but of particular objects being observed. In the history of Smalltalk-80 that I'm aware of from Smalltalk-80 v2 through to VisualWorks 7.x, copying did *not* copy dependents. In fact, in Model, where for efficiency, Model>>postCopy did self breakDependents. > > Before we go further, imagine inspecting some object. An inspector updates its view of the object being inspected whenever that object issues a changed method. Now let's inspect a copy of that object. Wth your implementation both inspectors update whenever either object changes state. This isn't at all what we want. > > Now for the actual bug. If you look at copy for Model in Squeak, copy does *not* break dependents, and hence we get the behaviour you (think you) want: > > > (Model new addDependent: Object new; copy) dependents => a DependentsArray(an Object) > > This is a bad bug, and I only discovered it when I looked for a counter-example to your suggestion andfound that Model did (IMO) the *wrong* thing. So if there is a bug, and I think there is, the fix is: > > Model>>postCopy > self breakDependents > > > 2. If you run exactly the same snippet with a Model instead of an Object (which implements dependencies in a different way under the hood), the copied object will contain the original dependencies, still. I think we should unify this undocumented and unintuitive discrepancy. The Model documentation states it features "fast dependents maintenance" so the behavior should be kept, just optimized. > > > > How do you think about this? > > Can we change the Object behavior or could this introduce any unpredictable consequences? > > And how could we fix it? > > > > And what about #shallowCopy? Unfortunately, it is called directly by more than a hundred senders in the Trunk image. Because DependentsFields is an implementation detail, I wonder whether #shallowCopy should copy the dependents as well. Should we move the actual primitive method to something like #primShallowCopy and in #shallowCopy, update DependentsFields after calling the primitive? Or do we rather consider #shallowCopy as a low-level method (similar to #veryDeepCopyWith: as apposed to #veryDeepCopy) and call it a code smell to call #shallowCopy from a far-away place? > > > > And LBNL: What should the following snippet output in your opinion? > > > > o1 := Object new. > o1 addDependent: 42. > o2 := o1 shallowCopy. > o1 addDependent: 43. > o2 dependents asArray. > > > Should it answer: a) #(), b) #(42), or c) #(42 43)? :D > > > > I am looking forward to your opinions! :-) > > > > Best, > > Christoph > > > > > -- > _,,,^..^,,,_ > best, Eliot > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Sat Aug 22 01:00:15 2020 From: tim at rowledge.org (tim Rowledge) Date: Fri, 21 Aug 2020 18:00:15 -0700 Subject: [squeak-dev] base64 encoding and CRs Message-ID: <04345B37-D805-4E93-B40B-7F952CA0EF5E@rowledge.org> As best I can see base64 encoding never results in the output having Character cr embedded, right? Why would I ask such a dumb question? Because I'm looking at some code that carefully does a copyReplaceAll: on a base64 encoded String that was a bitmap, and I can't imagine how that could ever not corrupt the bitmap *if* there were any chance it did indeed include CRs. And it's late on a Friday and to be honest, anything could be possible in 2020. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Useful random insult:- His spirit guide is a three-toed sloth. From vanessa at codefrau.net Sat Aug 22 01:29:15 2020 From: vanessa at codefrau.net (Vanessa Freudenberg) Date: Fri, 21 Aug 2020 18:29:15 -0700 Subject: [squeak-dev] base64 encoding and CRs In-Reply-To: <04345B37-D805-4E93-B40B-7F952CA0EF5E@rowledge.org> References: <04345B37-D805-4E93-B40B-7F952CA0EF5E@rowledge.org> Message-ID: Hi Tim, our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. Vanessa On Fri, Aug 21, 2020 at 6:00 PM tim Rowledge wrote: > As best I can see base64 encoding never results in the output having > Character cr embedded, right? > > Why would I ask such a dumb question? Because I'm looking at some code > that carefully does a copyReplaceAll: on a base64 encoded String that was a > bitmap, and I can't imagine how that could ever not corrupt the bitmap *if* > there were any chance it did indeed include CRs. > > And it's late on a Friday and to be honest, anything could be possible in > 2020. > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Useful random insult:- His spirit guide is a three-toed sloth. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbpublist at gmail.com Sat Aug 22 01:30:23 2020 From: pbpublist at gmail.com (Phil B) Date: Fri, 21 Aug 2020 21:30:23 -0400 Subject: [squeak-dev] base64 encoding and CRs In-Reply-To: <04345B37-D805-4E93-B40B-7F952CA0EF5E@rowledge.org> References: <04345B37-D805-4E93-B40B-7F952CA0EF5E@rowledge.org> Message-ID: Tim, Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table) At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day) Phil On Fri, Aug 21, 2020 at 9:00 PM tim Rowledge wrote: > As best I can see base64 encoding never results in the output having > Character cr embedded, right? > > Why would I ask such a dumb question? Because I'm looking at some code > that carefully does a copyReplaceAll: on a base64 encoded String that was a > bitmap, and I can't imagine how that could ever not corrupt the bitmap *if* > there were any chance it did indeed include CRs. > > And it's late on a Friday and to be honest, anything could be possible in > 2020. > > tim > -- > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim > Useful random insult:- His spirit guide is a three-toed sloth. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Sat Aug 22 04:35:42 2020 From: tim at rowledge.org (tim Rowledge) Date: Fri, 21 Aug 2020 21:35:42 -0700 Subject: [squeak-dev] base64 encoding and CRs In-Reply-To: References: <04345B37-D805-4E93-B40B-7F952CA0EF5E@rowledge.org> Message-ID: <5CAB7909-4B1B-4556-B725-5BC204440AA0@rowledge.org> > On 2020-08-21, at 6:30 PM, Phil B wrote: > > Tim, > > Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table) At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day) > > Phil > On 2020-08-21, at 6:29 PM, Vanessa Freudenberg wrote: > > Hi Tim, > > our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. > > Vanessa Hunh. Fascinating. So maybe there is a tiny bit of sense to the code I was peering tiredly at. Though given it was creating the base64 string right there, probably not in this case. I do love how the software word is so full of kludge upon jury-rig upon WAG! Thanks for the enlightenment. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim Strange OpCodes: UDF: Use Disk for Frisbee From Das.Linux at gmx.de Sat Aug 22 07:50:28 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Sat, 22 Aug 2020 09:50:28 +0200 Subject: [squeak-dev] base64 encoding and CRs In-Reply-To: <5CAB7909-4B1B-4556-B725-5BC204440AA0@rowledge.org> References: <04345B37-D805-4E93-B40B-7F952CA0EF5E@rowledge.org> <5CAB7909-4B1B-4556-B725-5BC204440AA0@rowledge.org> Message-ID: Hi > On 22.08.2020, at 06:35, tim Rowledge wrote: > > > >> On 2020-08-21, at 6:30 PM, Phil B wrote: >> >> Tim, >> >> Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table) At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day) >> >> Phil > > >> On 2020-08-21, at 6:29 PM, Vanessa Freudenberg wrote: >> >> Hi Tim, >> >> our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. >> >> Vanessa > > Hunh. Fascinating. So maybe there is a tiny bit of sense to the code I was peering tiredly at. Though given it was creating the base64 string right there, probably not in this case. I do love how the software word is so full of kludge upon jury-rig upon WAG! > > Thanks for the enlightenment. Look at the raw email I'm just replying to: =-=-=-= From: tim Rowledge Message-Id: <5CAB7909-4B1B-4556-B725-5BC204440AA0 at rowledge.org> Subject: Re: [squeak-dev] base64 encoding and CRs Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cgo+IE9uIDIwMjAtMDgtMjEsIGF0IDY6MzAgUE0sIFBoaWwgQiA8cGJwdWJsaXN0QGdtYWlsLmNv bT4gd3JvdGU6Cj4gCj4gVGltLAo+IAo+IENvcnJlY3QsIGJhc2U2NCBlbmNvZGluZyBvbmx5IGVt aXRzIGEgc3Vic2V0IG9mIHByaW50YWJsZSBjaGFyYWN0ZXJzIChzZWUgaHR0cHM6Ly9lbi53aWtp cGVkaWEub3JnL3dpa2kvQmFzZTY0I0Jhc2U2NF90YWJsZSkgIEF0IHlvdXIgb3B0aW9uLCB5b3Ug Y2FuIGFsc28gaW5zZXJ0IENSJ3MgaW50byBhIGJhc2U2NCBzdHJpbmcgd2hpY2ggc2hvdWxkIGJl IGlnbm9yZWQgb24gZGVjb2RpbmcuIChhcyB3YXMgY29tbW9uIGZvciB2YXJpb3VzIGVtYWlsIGNs aWVudHMgdG8gZG8gYmFjayBpbiB0aGUgZGF5KQo+IAo+IFBoaWwKCgo+IE9uIDIwMjAtMDgtMjEs IGF0IDY6MjkgUE0sIFZhbmVzc2EgRnJldWRlbmJlcmcgPHZhbmVzc2FAY29kZWZyYXUubmV0PiB3 cm90ZToKPiAKPiBIaSBUaW0sCj4gCj4gb3VyIGVuY29kZXIgbWlnaHQgbm90IGJlIHByb2R1Y2lu ZyBjcidzLCBidXQgYmFzZTY0IHBheWxvYWRzIGluIHRoZSB3aWxkIG9mdGVuIGhhdmUgbGluZXMg bm8gbG9uZ2VyIHRoYW4gODAgY2hhcmFjdGVycywgc28gYmVmb3JlIGRlY29kaW5nIGl0IG1ha2Vz IHNlbnNlIHRvIHJlbW92ZSB0aGF0LiAKPiAKPiBWYW5lc3NhCgpIdW5oLiBGYXNjaW5hdGluZy4g U28gbWF5YmUgdGhlcmUgaXMgYSB0aW55IGJpdCBvZiBzZW5zZSB0byB0aGUgY29kZSBJIHdhcyBw ZWVyaW5nIHRpcmVkbHkgYXQuIFRob3VnaCBnaXZlbiBpdCB3YXMgY3JlYXRpbmcgdGhlIGJhc2U2 NCBzdHJpbmcgcmlnaHQgdGhlcmUsIHByb2JhYmx5IG5vdCBpbiB0aGlzIGNhc2UuIEkgZG8gbG92 ZSBob3cgdGhlIHNvZnR3YXJlIHdvcmQgaXMgc28gZnVsbCBvZiBrbHVkZ2UgdXBvbiBqdXJ5LXJp ZyB1cG9uIFdBRyEKClRoYW5rcyBmb3IgdGhlIGVubGlnaHRlbm1lbnQuIAoKdGltCi0tCnRpbSBS b3dsZWRnZTsgdGltQHJvd2xlZGdlLm9yZzsgaHR0cDovL3d3dy5yb3dsZWRnZS5vcmcvdGltClN0 cmFuZ2UgT3BDb2RlczogVURGOiBVc2UgRGlzayBmb3IgRnJpc2JlZQoKCgo= =-=-=-=-= Wrapping Base64 is _extremely_ common. Virtually half the SSL Certificates are delivered that way… Pgp keys, signatures, SSH keys, … you name it :) Best regards -Tobias From Das.Linux at gmx.de Sat Aug 22 08:22:24 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Sat, 22 Aug 2020 10:22:24 +0200 Subject: [squeak-dev] base64 encoding and CRs In-Reply-To: References: <04345B37-D805-4E93-B40B-7F952CA0EF5E@rowledge.org> <5CAB7909-4B1B-4556-B725-5BC204440AA0@rowledge.org> Message-ID: > On 22.08.2020, at 09:50, Tobias Pape wrote: > > Hi > >> On 22.08.2020, at 06:35, tim Rowledge wrote: >> >> >> >>> On 2020-08-21, at 6:30 PM, Phil B wrote: >>> >>> Tim, >>> >>> Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table) At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day) >>> >>> Phil >> >> >>> On 2020-08-21, at 6:29 PM, Vanessa Freudenberg wrote: >>> >>> Hi Tim, >>> >>> our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. >>> >>> Vanessa >> >> Hunh. Fascinating. So maybe there is a tiny bit of sense to the code I was peering tiredly at. Though given it was creating the base64 string right there, probably not in this case. I do love how the software word is so full of kludge upon jury-rig upon WAG! >> >> Thanks for the enlightenment. > > Look at the raw email I'm just replying to: > > =-=-=-= > > From: tim Rowledge > Message-Id: <5CAB7909-4B1B-4556-B725-5BC204440AA0 at rowledge.org> > Subject: Re: [squeak-dev] base64 encoding and CRs > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: base64 > > Cgo+IE9uIDIwMjAtMDgtMjEsIGF0IDY6MzAgUE0sIFBoaWwgQiA8cGJwdWJsaXN0QGdtYWlsLmNv > bT4gd3JvdGU6Cj4gCj4gVGltLAo+IAo+IENvcnJlY3QsIGJhc2U2NCBlbmNvZGluZyBvbmx5IGVt > aXRzIGEgc3Vic2V0IG9mIHByaW50YWJsZSBjaGFyYWN0ZXJzIChzZWUgaHR0cHM6Ly9lbi53aWtp > cGVkaWEub3JnL3dpa2kvQmFzZTY0I0Jhc2U2NF90YWJsZSkgIEF0IHlvdXIgb3B0aW9uLCB5b3Ug > Y2FuIGFsc28gaW5zZXJ0IENSJ3MgaW50byBhIGJhc2U2NCBzdHJpbmcgd2hpY2ggc2hvdWxkIGJl > IGlnbm9yZWQgb24gZGVjb2RpbmcuIChhcyB3YXMgY29tbW9uIGZvciB2YXJpb3VzIGVtYWlsIGNs > aWVudHMgdG8gZG8gYmFjayBpbiB0aGUgZGF5KQo+IAo+IFBoaWwKCgo+IE9uIDIwMjAtMDgtMjEs > IGF0IDY6MjkgUE0sIFZhbmVzc2EgRnJldWRlbmJlcmcgPHZhbmVzc2FAY29kZWZyYXUubmV0PiB3 > cm90ZToKPiAKPiBIaSBUaW0sCj4gCj4gb3VyIGVuY29kZXIgbWlnaHQgbm90IGJlIHByb2R1Y2lu > ZyBjcidzLCBidXQgYmFzZTY0IHBheWxvYWRzIGluIHRoZSB3aWxkIG9mdGVuIGhhdmUgbGluZXMg > bm8gbG9uZ2VyIHRoYW4gODAgY2hhcmFjdGVycywgc28gYmVmb3JlIGRlY29kaW5nIGl0IG1ha2Vz > IHNlbnNlIHRvIHJlbW92ZSB0aGF0LiAKPiAKPiBWYW5lc3NhCgpIdW5oLiBGYXNjaW5hdGluZy4g > U28gbWF5YmUgdGhlcmUgaXMgYSB0aW55IGJpdCBvZiBzZW5zZSB0byB0aGUgY29kZSBJIHdhcyBw > ZWVyaW5nIHRpcmVkbHkgYXQuIFRob3VnaCBnaXZlbiBpdCB3YXMgY3JlYXRpbmcgdGhlIGJhc2U2 > NCBzdHJpbmcgcmlnaHQgdGhlcmUsIHByb2JhYmx5IG5vdCBpbiB0aGlzIGNhc2UuIEkgZG8gbG92 > ZSBob3cgdGhlIHNvZnR3YXJlIHdvcmQgaXMgc28gZnVsbCBvZiBrbHVkZ2UgdXBvbiBqdXJ5LXJp > ZyB1cG9uIFdBRyEKClRoYW5rcyBmb3IgdGhlIGVubGlnaHRlbm1lbnQuIAoKdGltCi0tCnRpbSBS > b3dsZWRnZTsgdGltQHJvd2xlZGdlLm9yZzsgaHR0cDovL3d3dy5yb3dsZWRnZS5vcmcvdGltClN0 > cmFuZ2UgT3BDb2RlczogVURGOiBVc2UgRGlzayBmb3IgRnJpc2JlZQoKCgo= > > =-=-=-=-= > > Wrapping Base64 is _extremely_ common. > Virtually half the SSL Certificates are delivered that way… Pgp keys, signatures, SSH keys, … you name it :) > Also: https://en.wikipedia.org/wiki/Base64#Variants_summary_table Best regards -Tobias From commits at source.squeak.org Sat Aug 22 09:47:49 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sat, 22 Aug 2020 09:47:49 0000 Subject: [squeak-dev] The Trunk: Graphics-kfr.436.mcz Message-ID: Karl Ramberg uploaded a new version of Graphics to project The Trunk: http://source.squeak.org/trunk/Graphics-kfr.436.mcz ==================== Summary ==================== Name: Graphics-kfr.436 Author: kfr Time: 22 August 2020, 11:47:40.557622 am UUID: 50875d76-6a37-3c49-a0b7-97d9186fb2d6 Ancestors: Graphics-mt.433 I wanted to subclass Rectangle with a instance variable to carry some state, but these methodes indirected to Point>>corner: so it broke the override and returned a ordinary Rectangle instead of my fancy new subclass SuperRectangle Updated to use #first to get the first element and #allButFirstDo: to iterate over the rest. (Suggested by Levente Uzonyi) =============== Diff against Graphics-mt.433 =============== Item was changed: ----- Method: Rectangle class>>encompassing: (in category 'instance creation') ----- encompassing: listOfPoints "A number of callers of encompass: should use this method." | topLeft bottomRight | + topLeft := bottomRight := listOfPoints first. + listOfPoints allButFirstDo: + [:p |topLeft := topLeft min: p. + bottomRight := bottomRight max: p]. + ^self origin: topLeft corner: bottomRight + ! - topLeft := bottomRight := nil. - listOfPoints do: - [:p | topLeft == nil - ifTrue: [topLeft := bottomRight := p] - ifFalse: [topLeft := topLeft min: p. - bottomRight := bottomRight max: p]]. - ^ topLeft corner: bottomRight! Item was changed: ----- Method: Rectangle class>>merging: (in category 'instance creation') ----- merging: listOfRects "A number of callers of merge: should use this method." + | bottomRight topLeft | + topLeft := listOfRects first topLeft. + bottomRight := listOfRects first bottomRight. - | minX minY maxX maxY | listOfRects + allButFirstDo: [:r | topLeft := topLeft min: r topLeft. + bottomRight := bottomRight max: r bottomRight]. + ^self origin: topLeft corner: bottomRight. + ! - do: [:r | minX - ifNil: [minX := r topLeft x. minY := r topLeft y. - maxX := r bottomRight x. maxY := r bottomRight y] - ifNotNil: [minX := minX min: r topLeft x. minY := minY min: r topLeft y. - maxX := maxX max: r bottomRight x. maxY := maxY max: r bottomRight y]]. - ^ minX at minY corner: maxX at maxY! From lewis at mail.msen.com Sat Aug 22 14:40:26 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Sat, 22 Aug 2020 10:40:26 -0400 Subject: [squeak-dev] base64 encoding and CRs In-Reply-To: <5CAB7909-4B1B-4556-B725-5BC204440AA0@rowledge.org> References: <04345B37-D805-4E93-B40B-7F952CA0EF5E@rowledge.org> <5CAB7909-4B1B-4556-B725-5BC204440AA0@rowledge.org> Message-ID: <20200822144026.GA90085@shell.msen.com> On Fri, Aug 21, 2020 at 09:35:42PM -0700, tim Rowledge wrote: > > > > On 2020-08-21, at 6:30 PM, Phil B wrote: > > > > Tim, > > > > Correct, base64 encoding only emits a subset of printable characters (see https://en.wikipedia.org/wiki/Base64#Base64_table) At your option, you can also insert CR's into a base64 string which should be ignored on decoding. (as was common for various email clients to do back in the day) > > > > Phil > > > > On 2020-08-21, at 6:29 PM, Vanessa Freudenberg wrote: > > > > Hi Tim, > > > > our encoder might not be producing cr's, but base64 payloads in the wild often have lines no longer than 80 characters, so before decoding it makes sense to remove that. > > > > Vanessa > > Hunh. Fascinating. So maybe there is a tiny bit of sense to the code I was peering tiredly at. Though given it was creating the base64 string right there, probably not in this case. I do love how the software word is so full of kludge upon jury-rig upon WAG! > > Thanks for the enlightenment. > Tim, I fear that you have been spending too much time immersing yourself the gratuitous improvements of modern technology. Surely you still remember how to connect your computer with a proper rotary dial phone and acoustic coupler. Once connected, you would use uuencode/uudecode (like base64) to send binary stuff to the uucp network in a shar archive. Naturally you would want to add line terminators in your encoded data, othewise people might not be able to view it in their vi text editor or text mail client. :-) Dave -- From builds at travis-ci.org Sat Aug 22 14:54:03 2020 From: builds at travis-ci.org (Travis CI) Date: Sat, 22 Aug 2020 14:54:03 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1801 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f41318a9a4a4_13f8168a9f5641273cd@travis-tasks-77c45c8c7b-j82mp.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1801 Status: Errored Duration: 17 mins and 30 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/720199813?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Sat Aug 22 17:34:59 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sat, 22 Aug 2020 17:34:59 0000 Subject: [squeak-dev] The Inbox: Morphic-ct.1677.mcz Message-ID: A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1677.mcz ==================== Summary ==================== Name: Morphic-ct.1677 Author: ct Time: 22 August 2020, 7:34:52.856555 pm UUID: 094ccc97-c3f6-364c-a10d-7418b3482703 Ancestors: Morphic-mt.1674 Nuke backward compatibility for Squeak 2.x menus. This should really not be relevant any longer I think. ;-) Also minor refactoring to MenuItemMorph >> #invokeWithEvent:. =============== Diff against Morphic-mt.1674 =============== Item was changed: ----- Method: MenuItemMorph>>invokeWithEvent: (in category 'events') ----- invokeWithEvent: evt "Perform the action associated with the given menu item." - | w | self isEnabled ifFalse: [^ self]. + + (owner notNil and: [self isStayUpItem not]) ifTrue: [ - target class == HandMorph ifTrue: [(self notObsolete) ifFalse: [^ self]]. - owner ifNotNil:[self isStayUpItem ifFalse:[ self flag: #workAround. "The tile system invokes menus straightforwardly so the menu might not be in the world." + self world ifNotNil: [:world | - (w := self world) ifNotNil:[ owner deleteIfPopUp: evt. "Repair damage before invoking the action for better feedback" + world displayWorldSafely]]. + + selector ifNil: [^ self]. + + Cursor normal showWhile: [ + "show cursor in case item opens a new MVC window" + selector numArgs isZero + ifTrue: [target perform: selector] + ifFalse: [target perform: selector withArguments: ( + selector numArgs = arguments size + ifTrue: [arguments] + ifFalse: [arguments copyWith: evt] )] ].! - w displayWorldSafely]]]. - selector ifNil:[^self]. - Cursor normal showWhile: [ | selArgCount | "show cursor in case item opens a new MVC window" - (selArgCount := selector numArgs) = 0 - ifTrue: - [target perform: selector] - ifFalse: - [selArgCount = arguments size - ifTrue: [target perform: selector withArguments: arguments] - ifFalse: [target perform: selector withArguments: (arguments copyWith: evt)]]].! Item was removed: - ----- Method: MenuItemMorph>>notObsolete (in category 'private') ----- - notObsolete - "Provide backward compatibility with messages being sent to the Hand. Remove this when no projects made prior to 2.9 are likely to be used. If this method is removed early, the worst that can happen is a notifier when invoking an item in an obsolete menu." - - (HandMorph canUnderstand: (selector)) ifTrue: [^ true]. "a modern one" - - self inform: 'This world menu is obsolete. - Please dismiss the menu and open a new one.'. - ^ false - ! From eliot.miranda at gmail.com Sat Aug 22 17:38:25 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 22 Aug 2020 10:38:25 -0700 Subject: [squeak-dev] Got FFI working on my own builds (production and debug) but downloaded all-in-one always never works In-Reply-To: <756E4228-4A03-46EF-8D55-AA9BFD6D56A8@cox.net> References: <756E4228-4A03-46EF-8D55-AA9BFD6D56A8@cox.net> Message-ID: Hi Lawson, On Thu, Aug 20, 2020 at 1:56 PM LawsonEnglish wrote: > So, with Craig Latta’s help, I managed to build my own vm. I added back in > the 5.3-19435 image and changes files, and sources file, and changed the > plist appropriately and it works just fine. > > Yay! > > However, I never did get the distributed version to work. I can sorta make > it work with enough swapping of files, but it eventually crashes on startup > even though FFI to my own dylib is working. > > The unmodified distributed 5.3 all-in-work apparently ALWAYS eventually > crashes onstartup after trying to load a dylib and then staving, if I do it > enough times, but thus far the ones I built do not do this. > If you run with an assert 5.3 VM build do you see anything indicative? And are you saying that the 5.3 distribution also crashes on a recent VM? > I can continue with my FFI experiments now (thanks everyone for their > help), but unless something is very wrong with my Mac’s setup, the latst > vesion of catalina isn’t stable for FFI via dylib. > > > L > _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at rowledge.org Sat Aug 22 17:41:59 2020 From: tim at rowledge.org (tim Rowledge) Date: Sat, 22 Aug 2020 10:41:59 -0700 Subject: [squeak-dev] base64 encoding and CRs In-Reply-To: <20200822144026.GA90085@shell.msen.com> References: <04345B37-D805-4E93-B40B-7F952CA0EF5E@rowledge.org> <5CAB7909-4B1B-4556-B725-5BC204440AA0@rowledge.org> <20200822144026.GA90085@shell.msen.com> Message-ID: > On 2020-08-22, at 7:40 AM, David T. Lewis wrote: > > I fear that you have been spending too much time immersing yourself the > gratuitous improvements of modern technology. Surely you still remember > how to connect your computer with a proper rotary dial phone and acoustic > coupler. Once connected, you would use uuencode/uudecode (like base64) > to send binary stuff to the uucp network in a shar archive. I missed that level of 'pleasure' by a couple of years but my first experiences with trying to sned data from one computer to another involved 'cables' made by soldering dress-maker's pins to wires in orderto be able to probe the DB15/25 connectors and work out which ones were the appropriate ones. Such fun! > > Naturally you would want to add line terminators in your encoded data, > othewise people might not be able to view it in their vi text editor or > text mail client. Oh yea, *those* people. It's ok though, there will be at least 42 emacs modes and add-ons to handle it for you, just so long as you have the proper emacs extended edition 432 key keyboard. With the full dozen meta keys. tim -- tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as he realised Piglet was undercooked. From commits at source.squeak.org Sat Aug 22 18:03:59 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sat, 22 Aug 2020 18:03:59 0000 Subject: [squeak-dev] The Inbox: SUnitGUI-ct.81.mcz Message-ID: A new version of SUnitGUI was added to project The Inbox: http://source.squeak.org/inbox/SUnitGUI-ct.81.mcz ==================== Summary ==================== Name: SUnitGUI-ct.81 Author: ct Time: 22 August 2020, 8:03:59.041378 pm UUID: 73e8b227-7520-354a-986c-5e8a5991afc6 Ancestors: SUnitGUI-mt.79 Fix selection updates in TestRunner by sending missing observer updates. Same reason as ToolBuilder-Morphic-ct.253. =============== Diff against SUnitGUI-mt.79 =============== Item was changed: ----- Method: TestRunner>>categoryAt:put: (in category 'accessing-categories') ----- categoryAt: anInteger put: aBoolean categoriesSelected := categoriesSelected perform: (aBoolean ifTrue: [ #copyWith: ] ifFalse: [ #copyWithout: ]) with: (categories at: anInteger ifAbsent: [ ^ self ]). + self + changed: #categoryAt:; + changed: #categorySelected; + updateClasses.! - self changed: #categorySelected; updateClasses.! Item was changed: ----- Method: TestRunner>>classAt:put: (in category 'accessing-classes') ----- classAt: anInteger put: aBoolean classesSelected := classesSelected perform: (aBoolean ifTrue: [ #copyWith: ] ifFalse: [ #copyWithout: ]) with: (classes at: anInteger ifAbsent: [ ^ self ]). + self + changed: #classAt:; + changed: #classSelected; + changed: #hasRunnable.! - self changed: #classSelected; changed: #hasRunnable.! From commits at source.squeak.org Sat Aug 22 18:05:31 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sat, 22 Aug 2020 18:05:31 0000 Subject: [squeak-dev] The Inbox: Tools-ct.985.mcz Message-ID: A new version of Tools was added to project The Inbox: http://source.squeak.org/inbox/Tools-ct.985.mcz ==================== Summary ==================== Name: Tools-ct.985 Author: ct Time: 22 August 2020, 8:05:25.644378 pm UUID: fcb716be-e917-2646-ade9-4c4550088392 Ancestors: Tools-eem.984 Fix selection updates in ChangeList by sending missing observer updates. Same reason as ToolBuilder-Morphic-ct.253. I also re-checked all other senders of #setSelectionList: in the Trunk image and did not found any further invalidation problems. =============== Diff against Tools-eem.984 =============== Item was changed: ----- Method: ChangeList>>listSelectionAt:put: (in category 'viewing access') ----- listSelectionAt: index put: value listSelections at: index put: value. + self + changed: #listSelectionAt:; + changed: #listIndex. - self changed: #listIndex. ^ value! From Christoph.Thiede at student.hpi.uni-potsdam.de Sat Aug 22 18:11:30 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Sat, 22 Aug 2020 18:11:30 +0000 Subject: [squeak-dev] Bug in #copy? In-Reply-To: References: , Message-ID: <416319c5cb584d36a45fe8ed1067b8bd@student.hpi.uni-potsdam.de> Hi all, thanks for the arguments, I see your point of identity-specific dependency management. I always found this tutorial [1] stating that "in some Smalltalks, Model redefines the method #postCopy to remove the dependents from the shallow #copy". This might be the most elegant solution. I'm going to upload something to the inbox :-) [1] http://www.bildungsgueter.de/Smalltalk/Pages/MVCTutorial/Pages/Model.htm#:~:text=Copying%20a%20Model Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Freitag, 21. August 2020 22:22:53 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Bug in #copy? My first impression also was that dependents should not observe the new object, be it a Model or anything else. Also Object has some template methods that in the base class do nothing. Since as Object has no state, it makes sense to me that its postCopy method should do nothing. Eliot Miranda > schrieb am Fr., 21. Aug. 2020, 21:26: Hi Christoph, On Fri, Aug 21, 2020 at 10:55 AM Thiede, Christoph > wrote: Hi all, please consider the following snippet and its output: o := Object new. o addDependent: 42. o copy dependents. "#()" In my opinion, this behavior is misleading for two reasons: 1. #copy is documented as to "answer another instance just like the receiver." From an abstract view of the object, this should include the object's dependents, too. Afaik, DependentsFields is only an implementation detail, but in common sense, the dependents are just another part of the object. I disagree. Dependents are a mechanism for observing an object. They allow external objects to register interest in a particular instance. Those observers are not interested in observing the state of arbitrary copies, but of particular objects being observed. In the history of Smalltalk-80 that I'm aware of from Smalltalk-80 v2 through to VisualWorks 7.x, copying did *not* copy dependents. In fact, in Model, where for efficiency, Model>>postCopy did self breakDependents. Before we go further, imagine inspecting some object. An inspector updates its view of the object being inspected whenever that object issues a changed method. Now let's inspect a copy of that object. Wth your implementation both inspectors update whenever either object changes state. This isn't at all what we want. Now for the actual bug. If you look at copy for Model in Squeak, copy does *not* break dependents, and hence we get the behaviour you (think you) want: (Model new addDependent: Object new; copy) dependents => a DependentsArray(an Object) This is a bad bug, and I only discovered it when I looked for a counter-example to your suggestion andfound that Model did (IMO) the *wrong* thing. So if there is a bug, and I think there is, the fix is: Model>>postCopy self breakDependents 2. If you run exactly the same snippet with a Model instead of an Object (which implements dependencies in a different way under the hood), the copied object will contain the original dependencies, still. I think we should unify this undocumented and unintuitive discrepancy. The Model documentation states it features "fast dependents maintenance" so the behavior should be kept, just optimized. How do you think about this? Can we change the Object behavior or could this introduce any unpredictable consequences? And how could we fix it? And what about #shallowCopy? Unfortunately, it is called directly by more than a hundred senders in the Trunk image. Because DependentsFields is an implementation detail, I wonder whether #shallowCopy should copy the dependents as well. Should we move the actual primitive method to something like #primShallowCopy and in #shallowCopy, update DependentsFields after calling the primitive? Or do we rather consider #shallowCopy as a low-level method (similar to #veryDeepCopyWith: as apposed to #veryDeepCopy) and call it a code smell to call #shallowCopy from a far-away place? And LBNL: What should the following snippet output in your opinion? o1 := Object new. o1 addDependent: 42. o2 := o1 shallowCopy. o1 addDependent: 43. o2 dependents asArray. Should it answer: a) #(), b) #(42), or c) #(42 43)? :D I am looking forward to your opinions! :-) Best, Christoph -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Sat Aug 22 18:18:25 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sat, 22 Aug 2020 18:18:25 0000 Subject: [squeak-dev] The Inbox: Kernel-ct.1338.mcz Message-ID: A new version of Kernel was added to project The Inbox: http://source.squeak.org/inbox/Kernel-ct.1338.mcz ==================== Summary ==================== Name: Kernel-ct.1338 Author: ct Time: 22 August 2020, 8:18:22.970378 pm UUID: 2ab1921f-016a-7044-9b35-75f940130863 Ancestors: Kernel-dtl.1336 Break dependents when copying a model For the full discussion, see this thread: http://forum.world.st/Bug-in-copy-td5120761.html =============== Diff against Kernel-dtl.1336 =============== Item was added: + ----- Method: Model>>postCopy (in category 'copying') ----- + postCopy + + super postCopy. + self breakDependents.! From commits at source.squeak.org Sat Aug 22 18:20:01 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sat, 22 Aug 2020 18:20:01 0000 Subject: [squeak-dev] The Inbox: KernelTests-ct.385.mcz Message-ID: A new version of KernelTests was added to project The Inbox: http://source.squeak.org/inbox/KernelTests-ct.385.mcz ==================== Summary ==================== Name: KernelTests-ct.385 Author: ct Time: 22 August 2020, 8:20:01.189378 pm UUID: 7b38e1cc-215c-8446-999e-0b702ed39766 Ancestors: KernelTests-eem.384 Test copying of the dependents array Complements Kernel-ct.1338. For more details, see http://forum.world.st/Bug-in-copy-td5120761.html. =============== Diff against KernelTests-eem.384 =============== Item was changed: SystemOrganization addCategory: #'KernelTests-Classes'! SystemOrganization addCategory: #'KernelTests-Methods'! SystemOrganization addCategory: #'KernelTests-Numbers'! SystemOrganization addCategory: #'KernelTests-Objects'! SystemOrganization addCategory: #'KernelTests-Processes'! SystemOrganization addCategory: #'KernelTests-WriteBarrier'! + SystemOrganization addCategory: #'KernelTests-Models'! Item was added: + TestCase subclass: #ModelTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'KernelTests-Models'! Item was added: + ----- Method: ModelTest>>testCopyDependents (in category 'tests') ----- + testCopyDependents + + | bar foo | + foo := Model new. + foo addDependent: 42. + self assert: {42} equals: foo dependents asArray. + + bar := foo copy. + self assert: bar dependents isEmpty.! Item was added: + ----- Method: ObjectTest>>testCopyDependents (in category 'tests') ----- + testCopyDependents + + | bar foo | + foo := Object new. + foo addDependent: 42. + self assert: {42} equals: foo dependents asArray. + + bar := foo copy. + self assert: bar dependents isEmpty.! From craig at blackpagedigital.com Sat Aug 22 22:51:23 2020 From: craig at blackpagedigital.com (Craig Latta) Date: Sat, 22 Aug 2020 15:51:23 -0700 Subject: [squeak-dev] Bug in #copy? In-Reply-To: <0FD0B6CF-D705-4C48-8101-8C8CC756A04F@gmail.com> References: <1845775198.4317897.1598049178459@mail.yahoo.com> <0FD0B6CF-D705-4C48-8101-8C8CC756A04F@gmail.com> Message-ID: > I vote to block this person. Seconded. Done. -C -- Craig Latta Black Page Digital Berkeley, California blackpagedigital.com From commits at source.squeak.org Sun Aug 23 02:09:50 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 23 Aug 2020 02:09:50 0000 Subject: [squeak-dev] The Trunk: KernelTests-ct.385.mcz Message-ID: Eliot Miranda uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-ct.385.mcz ==================== Summary ==================== Name: KernelTests-ct.385 Author: ct Time: 22 August 2020, 8:20:01.189378 pm UUID: 7b38e1cc-215c-8446-999e-0b702ed39766 Ancestors: KernelTests-eem.384 Test copying of the dependents array Complements Kernel-ct.1338. For more details, see http://forum.world.st/Bug-in-copy-td5120761.html. =============== Diff against KernelTests-eem.384 =============== Item was changed: SystemOrganization addCategory: #'KernelTests-Classes'! SystemOrganization addCategory: #'KernelTests-Methods'! SystemOrganization addCategory: #'KernelTests-Numbers'! SystemOrganization addCategory: #'KernelTests-Objects'! SystemOrganization addCategory: #'KernelTests-Processes'! SystemOrganization addCategory: #'KernelTests-WriteBarrier'! + SystemOrganization addCategory: #'KernelTests-Models'! Item was added: + TestCase subclass: #ModelTest + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'KernelTests-Models'! Item was added: + ----- Method: ModelTest>>testCopyDependents (in category 'tests') ----- + testCopyDependents + + | bar foo | + foo := Model new. + foo addDependent: 42. + self assert: {42} equals: foo dependents asArray. + + bar := foo copy. + self assert: bar dependents isEmpty.! Item was added: + ----- Method: ObjectTest>>testCopyDependents (in category 'tests') ----- + testCopyDependents + + | bar foo | + foo := Object new. + foo addDependent: 42. + self assert: {42} equals: foo dependents asArray. + + bar := foo copy. + self assert: bar dependents isEmpty.! From commits at source.squeak.org Sun Aug 23 02:10:45 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 23 Aug 2020 02:10:45 0000 Subject: [squeak-dev] The Trunk: Kernel-ct.1338.mcz Message-ID: Eliot Miranda uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-ct.1338.mcz ==================== Summary ==================== Name: Kernel-ct.1338 Author: ct Time: 22 August 2020, 8:18:22.970378 pm UUID: 2ab1921f-016a-7044-9b35-75f940130863 Ancestors: Kernel-dtl.1336 Break dependents when copying a model For the full discussion, see this thread: http://forum.world.st/Bug-in-copy-td5120761.html =============== Diff against Kernel-dtl.1336 =============== Item was added: + ----- Method: Model>>postCopy (in category 'copying') ----- + postCopy + + super postCopy. + self breakDependents.! From commits at source.squeak.org Sun Aug 23 02:11:43 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 23 Aug 2020 02:11:43 0000 Subject: [squeak-dev] The Trunk: Tools-ct.985.mcz Message-ID: Eliot Miranda uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-ct.985.mcz ==================== Summary ==================== Name: Tools-ct.985 Author: ct Time: 22 August 2020, 8:05:25.644378 pm UUID: fcb716be-e917-2646-ade9-4c4550088392 Ancestors: Tools-eem.984 Fix selection updates in ChangeList by sending missing observer updates. Same reason as ToolBuilder-Morphic-ct.253. I also re-checked all other senders of #setSelectionList: in the Trunk image and did not found any further invalidation problems. =============== Diff against Tools-eem.984 =============== Item was changed: ----- Method: ChangeList>>listSelectionAt:put: (in category 'viewing access') ----- listSelectionAt: index put: value listSelections at: index put: value. + self + changed: #listSelectionAt:; + changed: #listIndex. - self changed: #listIndex. ^ value! From commits at source.squeak.org Sun Aug 23 02:12:30 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 23 Aug 2020 02:12:30 0000 Subject: [squeak-dev] The Trunk: SUnitGUI-ct.81.mcz Message-ID: Eliot Miranda uploaded a new version of SUnitGUI to project The Trunk: http://source.squeak.org/trunk/SUnitGUI-ct.81.mcz ==================== Summary ==================== Name: SUnitGUI-ct.81 Author: ct Time: 22 August 2020, 8:03:59.041378 pm UUID: 73e8b227-7520-354a-986c-5e8a5991afc6 Ancestors: SUnitGUI-mt.79 Fix selection updates in TestRunner by sending missing observer updates. Same reason as ToolBuilder-Morphic-ct.253. =============== Diff against SUnitGUI-mt.79 =============== Item was changed: ----- Method: TestRunner>>categoryAt:put: (in category 'accessing-categories') ----- categoryAt: anInteger put: aBoolean categoriesSelected := categoriesSelected perform: (aBoolean ifTrue: [ #copyWith: ] ifFalse: [ #copyWithout: ]) with: (categories at: anInteger ifAbsent: [ ^ self ]). + self + changed: #categoryAt:; + changed: #categorySelected; + updateClasses.! - self changed: #categorySelected; updateClasses.! Item was changed: ----- Method: TestRunner>>classAt:put: (in category 'accessing-classes') ----- classAt: anInteger put: aBoolean classesSelected := classesSelected perform: (aBoolean ifTrue: [ #copyWith: ] ifFalse: [ #copyWithout: ]) with: (classes at: anInteger ifAbsent: [ ^ self ]). + self + changed: #classAt:; + changed: #classSelected; + changed: #hasRunnable.! - self changed: #classSelected; changed: #hasRunnable.! From eliot.miranda at gmail.com Sun Aug 23 02:14:16 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Sat, 22 Aug 2020 19:14:16 -0700 Subject: [squeak-dev] The Inbox: Morphic-ct.1677.mcz In-Reply-To: References: Message-ID: Hi Christoph, I haven't copied this to trunk. not because it looks bad (it doesn't), but because I'm not qualified. Better someone who knows menus better than I does the integration. On Sat, Aug 22, 2020 at 10:35 AM wrote: > A new version of Morphic was added to project The Inbox: > http://source.squeak.org/inbox/Morphic-ct.1677.mcz > > ==================== Summary ==================== > > Name: Morphic-ct.1677 > Author: ct > Time: 22 August 2020, 7:34:52.856555 pm > UUID: 094ccc97-c3f6-364c-a10d-7418b3482703 > Ancestors: Morphic-mt.1674 > > Nuke backward compatibility for Squeak 2.x menus. This should really not > be relevant any longer I think. ;-) > > Also minor refactoring to MenuItemMorph >> #invokeWithEvent:. > > =============== Diff against Morphic-mt.1674 =============== > > Item was changed: > ----- Method: MenuItemMorph>>invokeWithEvent: (in category 'events') > ----- > invokeWithEvent: evt > "Perform the action associated with the given menu item." > > - | w | > self isEnabled ifFalse: [^ self]. > + > + (owner notNil and: [self isStayUpItem not]) ifTrue: [ > - target class == HandMorph ifTrue: [(self notObsolete) ifFalse: [^ > self]]. > - owner ifNotNil:[self isStayUpItem ifFalse:[ > self flag: #workAround. "The tile system invokes menus > straightforwardly so the menu might not be in the world." > + self world ifNotNil: [:world | > - (w := self world) ifNotNil:[ > owner deleteIfPopUp: evt. > "Repair damage before invoking the action for > better feedback" > + world displayWorldSafely]]. > + > + selector ifNil: [^ self]. > + > + Cursor normal showWhile: [ > + "show cursor in case item opens a new MVC window" > + selector numArgs isZero > + ifTrue: [target perform: selector] > + ifFalse: [target perform: selector > withArguments: ( > + selector numArgs = arguments size > + ifTrue: [arguments] > + ifFalse: [arguments > copyWith: evt] )] ].! > - w displayWorldSafely]]]. > - selector ifNil:[^self]. > - Cursor normal showWhile: [ | selArgCount | "show cursor in case > item opens a new MVC window" > - (selArgCount := selector numArgs) = 0 > - ifTrue: > - [target perform: selector] > - ifFalse: > - [selArgCount = arguments size > - ifTrue: [target perform: selector > withArguments: arguments] > - ifFalse: [target perform: selector > withArguments: (arguments copyWith: evt)]]].! > > Item was removed: > - ----- Method: MenuItemMorph>>notObsolete (in category 'private') ----- > - notObsolete > - "Provide backward compatibility with messages being sent to the > Hand. Remove this when no projects made prior to 2.9 are likely to be > used. If this method is removed early, the worst that can happen is a > notifier when invoking an item in an obsolete menu." > - > - (HandMorph canUnderstand: (selector)) ifTrue: [^ true]. "a > modern one" > - > - self inform: 'This world menu is obsolete. > - Please dismiss the menu and open a new one.'. > - ^ false > - ! > > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From forums.jakob at resfarm.de Sun Aug 23 11:48:00 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Sun, 23 Aug 2020 13:48:00 +0200 Subject: [squeak-dev] [BUG] Text drag and drop to workspace unreliable In-Reply-To: <2d1990eb9515419589eb10e97d48c105@student.hpi.uni-potsdam.de> References: <2d1990eb9515419589eb10e97d48c105@student.hpi.uni-potsdam.de> Message-ID: Hi Christoph, After merging Morphic-ct.1675 and Morphic-ct.1676, it works as expected, thank you. Without ct.1676 the source workspace is not updated until it regains the keyboard focus, as described in the commit message. Kind regards, Jakob Am Do., 20. Aug. 2020 um 18:39 Uhr schrieb Thiede, Christoph : > > Hi Jakob, > > > does Morphic-ct.1675 resolve the issue for you? :-) > > > Best, > > Christoph > > ________________________________ > Von: Squeak-dev im Auftrag von Jakob Reschke > Gesendet: Sonntag, 29. Dezember 2019 21:40:19 > An: squeak-dev at lists.squeakfoundation.org > Betreff: [squeak-dev] [BUG] Text drag and drop to workspace unreliable > > Hi, > > I just noticed that the newly introduced text drag and drop sometimes does not work when dragging text between workspaces. It has always worked until today so I suspect the culprit is among the more recent changes. > > Problem: > When dragging the selected text from one workspace to another, sometimes an object reference is copied to the bindings of the workspace instead of pasting the text. In the target text, the newly created variable name appears instead (e. g. text3997962) as if I had dropped another non-text object. > > At least the text is not removed from the source workspace when this happens... > > Problem #2: > It does not always happen. When dragging from a third workspace it suddenly worked and then also from the second again. Then I reset my texts back to the old state and now it is broken again. > > Expected behavior: > The selected text from the source workspace is cut from there, and pasted at the drop hand location in the target workspace. > > Currently I have three workspaces #1, #2, #3. > If I drag the selection from #1 to #2, it works. > If I drag from #1 to #3 it does not. > Dragging from #2 to #3 does not work. > Dragging from #2 to #1 does work. > Now dragging from #1 to #3 suddenly does work... I dragged to the start of the text this time. > Dragging back from #3 to #1 works. > Dragging from #1 to #3 to the end of it also works. > Dragging back from #1 to #3. > Resetting (Cmd+l, lowercase L) text of #3. > Dragging from #1 to the end of #3 does not work again. Variable pasted at the start of the text. > Repeated dragging of the same text from #1 to #3 always pastes the variable. > Dragging to the middle of #3 works! > Dragging the pasted text inside of #3 to the end removed the text and pasted a variable instead. > > Hypothesis: it does not work to drop the text beyond the TextMorphForEditView. And so far I might just have been lucky to always have enough blank lines at the end of my target workspace. Workspaces #1 and #2 from above contain much more text than #3 and fill the whole editing area of the workspace, so this would be consistent. > > Squeak5.3beta > latest update: #19300 > > Kind regards, > Jakob > From forums.jakob at resfarm.de Sun Aug 23 11:50:43 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Sun, 23 Aug 2020 13:50:43 +0200 Subject: [squeak-dev] The Inbox: Morphic-ct.1675.mcz In-Reply-To: References: Message-ID: +1 together with Morphic-ct.1676 Christoph, do I assume correctly that this code won't be reached if the textMorph already processed the event because it was large enough? Could there be a double delivery of the event to the text morph under any circumstances? Am Do., 20. Aug. 2020 um 18:38 Uhr schrieb : > > A new version of Morphic was added to project The Inbox: > http://source.squeak.org/inbox/Morphic-ct.1675.mcz > > ==================== Summary ==================== > > Name: Morphic-ct.1675 > Author: ct > Time: 20 August 2020, 6:38:23.443941 pm > UUID: b76420e2-369c-7547-89c9-e553ffc4aa7c > Ancestors: Morphic-mt.1674 > > Proposal to fix unreliable text dragging into text morphs as described in http://forum.world.st/BUG-Text-drag-and-drop-to-workspace-unreliable-td5109035.html > > =============== Diff against Morphic-mt.1674 =============== > > Item was added: > + ----- Method: PluggableTextMorph>>handleDropMorph: (in category 'dropping/grabbing') ----- > + handleDropMorph: anEvent > + > + "Give TextMorphForEditView another chance to handle the drop. It did not get any chance before if it is smaller than ourselves." > + textMorph handleDropMorph: anEvent. > + > + "If the event has been handled now, super will ignore it." > + ^ super handleDropMorph: anEvent! > > From forums.jakob at resfarm.de Sun Aug 23 11:56:41 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Sun, 23 Aug 2020 13:56:41 +0200 Subject: [squeak-dev] [BUG] Pressing Tab on empty PluggableTreeMorph results in ZeroDivide In-Reply-To: <41545d04c05a4ae2843dca7c41e287e6@student.hpi.uni-potsdam.de> References: <41545d04c05a4ae2843dca7c41e287e6@student.hpi.uni-potsdam.de> Message-ID: Hi Christoph, I don't have my empty tree view any more, but when I load your method change and run the example you gave in the commit message, there is no error any more. Kind regards, Jakob Am Fr., 19. Juni 2020 um 16:24 Uhr schrieb Thiede, Christoph : > > Hi Jakob, > > > does Morphic-ct.1589 (Inbox) fix the issue for you? > > > Best, > > Christoph > > ________________________________ > Von: Squeak-dev im Auftrag von Jakob Reschke > Gesendet: Mittwoch, 17. Juni 2020 23:33:08 > An: squeak-dev at lists.squeakfoundation.org > Betreff: [squeak-dev] [BUG] Pressing Tab on empty PluggableTreeMorph results in ZeroDivide > > Hello all, > > I just hit Tab on an empty tree by accident. Turns out it results in a > division by zero because the submorphs list is empty. > > Kind regards, > Jakob > > > > 17 June 2020 11:30:25.651392 pm > > VM: Win32 - Smalltalk > Image: Squeak6.0alpha [latest update: #19752] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir C:\Users\Jakob\HiDrive > Trusted Dir C:\Users\Jakob\HiDrive\Jakob > Untrusted Dir C:\Users\Jakob\Documents\My Squeak > > SmallInteger>>/ > Receiver: 190 > Arguments and temporary variables: > aNumber: 0 > Receiver's instance variables: > 190 > > TransformMorph>>numberOfItemsPotentiallyInView > Receiver: a TransformMorph(4176857) > Arguments and temporary variables: > lsBounds: 781 at 179 corner: 1202 at 369 > Receiver's instance variables: > bounds: 781 at 179 corner: 1202 at 369 > owner: a PluggableTreeMorph(853321) > submorphs: #() > fullBounds: 781 at 179 corner: 1202 at 369 > color: Color transparent > extension: a MorphExtension (2383097) [other: (animations -> an > OrderedCollect...etc... > transform: a MorphicTransform(angle = 0.0; scale = 1.0; offset = -781@ -179) > smoothing: 1 > localBounds: 781 at 179 corner: 1202 at 369 > > PluggableTreeMorph(ScrollPane)>>numSelectionsInView > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > PluggableTreeMorph(SimpleHierarchicalListMorph)>>arrowKey: > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > asciiValue: 9 > keyEvent: 9 > max: 0 > oldSelection: 0 > nextSelection: 0 > howManyItemsShowing: nil > keyHandled: false > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > PluggableTreeMorph(SimpleHierarchicalListMorph)>>specialKeyPressed: > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > asciiValue: 9 > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > PluggableTreeMorph>>specialKeyPressed: > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > asciiValue: 9 > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > PluggableTreeMorph(SimpleHierarchicalListMorph)>>keyStroke: > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > event: [971 at 299 keystroke '' (9) 102540109] > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > PluggableTreeMorph>>keyStroke: > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > event: [971 at 299 keystroke '' (9) 102540109] > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > PluggableTreeMorph(Morph)>>handleKeystroke: > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > anEvent: [971 at 299 keystroke '' (9) 102540109] > handler: a PluggableTreeMorph(853321) > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > KeyboardEvent>>sentTo: > Receiver: [971 at 299 keystroke '' (9) 102540109] > Arguments and temporary variables: > anObject: a PluggableTreeMorph(853321) > Receiver's instance variables: > timeStamp: 102540109 > source: a HandMorph(3499674) > type: #keystroke > buttons: 0 > position: 971 at 299 > handler: a PluggableTreeMorph(853321) > wasHandled: true > wasIgnored: false > keyValue: 9 > > PluggableTreeMorph(Morph)>>handleEvent: > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > anEvent: [971 at 299 keystroke '' (9) 102540109] > filteredEvent: [971 at 299 keystroke '' (9) 102540109] > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > PluggableTreeMorph(Morph)>>handleFocusEvent: > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > anEvent: [971 at 299 keystroke '' (9) 102540109] > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > MorphicEventDispatcher>>doHandlingForFocusEvent:with: > Receiver: a MorphicEventDispatcher > Arguments and temporary variables: > currentEvent: [971 at 299 keystroke '' (9) 102540109] > focusMorph: a PluggableTreeMorph(853321) > localEvent: [971 at 299 keystroke '' (9) 102540109] > filteredEvent: nil > Receiver's instance variables: > lastType: nil > lastDispatch: nil > > MorphicEventDispatcher>>dispatchFocusEvent:with: > Receiver: a MorphicEventDispatcher > Arguments and temporary variables: > anEventWithGlobalPosition: [971 at 299 keystroke '' (9) 102540109] > focusMorph: a PluggableTreeMorph(853321) > currentEvent: [971 at 299 keystroke '' (9) 102540109] > Receiver's instance variables: > lastType: nil > lastDispatch: nil > > PluggableTreeMorph(Morph)>>processFocusEvent:using: > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > anEvent: [971 at 299 keystroke '' (9) 102540109] > defaultDispatcher: a MorphicEventDispatcher > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > PluggableTreeMorph(Morph)>>processFocusEvent: > Receiver: a PluggableTreeMorph(853321) > Arguments and temporary variables: > anEvent: [971 at 299 keystroke '' (9) 102540109] > Receiver's instance variables: > bounds: 781 at 179 corner: 1212 at 379 > owner: a PluggablePanelMorph(2744773) > submorphs: {a TransformMorph(4176857)} > fullBounds: 781 at 179 corner: 1212 at 379 > color: (Color r: 0.0 g: 0.169 b: 0.212) > extension: a MorphExtension (1683625) [eventHandler = an EventHandler > recipient...etc... > borderWidth: 0 > borderColor: (Color r: 0.001 g: 0.004 b: 0.005) > model: a SquitBrowser > slotName: nil > open: false > scrollBar: a ScrollBar(3978775) > scroller: a TransformMorph(4176857) > retractableScrollBar: false > scrollBarOnLeft: false > getMenuSelector: #commitListMenu: > getMenuTitleSelector: nil > hasFocus: false > hScrollBar: a ScrollBar(825607) > hScrollBarPolicy: #whenNeeded > vScrollBarPolicy: #whenNeeded > scrollBarThickness: 10 > selectedMorph: nil > hoveredMorph: nil > getListSelector: nil > keystrokeActionSelector: #commitListKey:from: > autoDeselect: true > columns: {[closure] in SquitBrowser>>buildCommitList: . [closure] in > SquitBrowser...etc... > columnsCache: #(107 108 nil) > sortingSelector: nil > getSelectionSelector: #commitSelection > setSelectionSelector: #commitSelection: > potentialDropMorph: nil > lineColor: (Color r: 0.345 g: 0.431 b: 0.458) > font: a StrikeFont(Darkmap DejaVu Sans9 14) > textColor: (Color r: 0.577 g: 0.631 b: 0.631) > rootWrappers: #() > selectedWrapper: nil > getRootsSelector: #commitList > getChildrenSelector: nil > hasChildrenSelector: nil > getLabelSelector: nil > getIconSelector: nil > getSelectedPathSelector: nil > setSelectedPathSelector: nil > setSelectedParentSelector: nil > getHelpSelector: nil > dropItemSelector: nil > wantsDropSelector: nil > dragItemSelector: #dragFromCommitList: > dragTypeSelector: nil > nodeClass: SquitVersionWrapper > lastKeystrokeTime: 0 > lastKeystrokes: '' > dragStartedSelector: nil > doubleClickSelector: nil > > [] in [] in [] in HandMorph>>sendFocusEvent:to:clear: > Receiver: a HandMorph(3499674) > Arguments and temporary variables: > < > Receiver's instance variables: > bounds: 1079 at 598 corner: 1095 at 614 > owner: a PasteUpMorph(2465254) [world] > submorphs: #() > fullBounds: 1079 at 598 corner: 1095 at 614 > color: Color blue > extension: a MorphExtension (1044607) [other: (balloonHelpMorphs -> > an Ordered...etc... > mouseFocus: nil > keyboardFocus: a PluggableListMorphPlus(1886198) > eventListeners: nil > mouseListeners: nil > keyboardListeners: nil > eventCaptureFilters: nil > mouseCaptureFilters: nil > keyboardCaptureFilters: a WeakArray(a HandMorph(3499674)) > mouseClickState: nil > mouseOverHandler: a MouseOverHandler > targetOffset: 75 at 13 > lastMouseEvent: [1079 at 598 mouseUp ( red ) 102549328] > damageRecorder: a DamageRecorder > cacheCanvas: nil > cachedCanvasHasHoles: false > temporaryCursor: nil > temporaryCursorOffset: nil > hardwareCursor: nil > hasChanged: true > savedPatch: nil > userInitials: '' > lastEventBuffer: #(1 102549328 1079 598 0 0 1 1) > genieGestureProcessor: nil > keyboardInterpreter: an UTF32InputInterpreter > > FullBlockClosure(BlockClosure)>>ensure: > Receiver: [closure] in [] in [] in HandMorph>>sendFocusEvent:to:clear: > Arguments and temporary variables: > aBlock: [closure] in KeyboardEvent(MorphicEvent)>>becomeActiveDuring: > complete: nil > returnValue: nil > Receiver's instance variables: > outerContext: [] in [] in HandMorph>>sendFocusEvent:to:clear: > startpcOrMethod: ([] in HandMorph>>#sendFocusEvent:to:clear: "a > CompiledBlock(2...etc... > numArgs: 0 > receiver: a HandMorph(3499674) > > KeyboardEvent(MorphicEvent)>>becomeActiveDuring: > Receiver: [971 at 299 keystroke '' (9) 102540109] > Arguments and temporary variables: > aBlock: [closure] in [] in [] in HandMorph>>sendFocusEvent:to:clear: > priorEvent: [963 at 285 keystroke '' (9) 102497593] > Receiver's instance variables: > timeStamp: 102540109 > source: a HandMorph(3499674) > type: #keystroke > buttons: 0 > position: 971 at 299 > handler: nil > wasHandled: false > wasIgnored: false > keyValue: 9 > > > --- The full stack --- > SmallInteger>>/ > TransformMorph>>numberOfItemsPotentiallyInView > PluggableTreeMorph(ScrollPane)>>numSelectionsInView > PluggableTreeMorph(SimpleHierarchicalListMorph)>>arrowKey: > PluggableTreeMorph(SimpleHierarchicalListMorph)>>specialKeyPressed: > PluggableTreeMorph>>specialKeyPressed: > PluggableTreeMorph(SimpleHierarchicalListMorph)>>keyStroke: > PluggableTreeMorph>>keyStroke: > PluggableTreeMorph(Morph)>>handleKeystroke: > KeyboardEvent>>sentTo: > PluggableTreeMorph(Morph)>>handleEvent: > PluggableTreeMorph(Morph)>>handleFocusEvent: > MorphicEventDispatcher>>doHandlingForFocusEvent:with: > MorphicEventDispatcher>>dispatchFocusEvent:with: > PluggableTreeMorph(Morph)>>processFocusEvent:using: > PluggableTreeMorph(Morph)>>processFocusEvent: > [] in [] in [] in HandMorph>>sendFocusEvent:to:clear: > FullBlockClosure(BlockClosure)>>ensure: > KeyboardEvent(MorphicEvent)>>becomeActiveDuring: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > [] in [] in HandMorph>>sendFocusEvent:to:clear: > FullBlockClosure(BlockClosure)>>ensure: > HandMorph>>becomeActiveDuring: > [] in HandMorph>>sendFocusEvent:to:clear: > FullBlockClosure(BlockClosure)>>ensure: > PasteUpMorph>>becomeActiveDuring: > HandMorph>>sendFocusEvent:to:clear: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendKeyboardEvent: > HandMorph>>handleEvent: > HandMorph>>processEvents > [] in AnimWorldState(WorldState)>>doOneCycleNowFor: > Array(SequenceableCollection)>>do: > AnimWorldState(WorldState)>>handsDo: > AnimWorldState(WorldState)>>doOneCycleNowFor: > AnimWorldState(WorldState)>>doOneCycleFor: > PasteUpMorph>>doOneCycle > [] in AnimMorphicProject>>spawnNewProcess > [] in FullBlockClosure(BlockClosure)>>newProcess > > > From builds at travis-ci.org Sun Aug 23 14:54:51 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 23 Aug 2020 14:54:51 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1802 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f42833b3c694_13fb8cf61cf5c196158@travis-tasks-865f7bb6c5-2mkl6.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1802 Status: Errored Duration: 17 mins and 39 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/720386461?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From LEnglish5 at cox.net Mon Aug 24 06:49:39 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Sun, 23 Aug 2020 23:49:39 -0700 Subject: [squeak-dev] test In-Reply-To: References: <756E4228-4A03-46EF-8D55-AA9BFD6D56A8@cox.net> Message-ID: <0F8239BB-08B2-4B6C-81CC-2A4DECC576E9@cox.net> test From LEnglish5 at cox.net Mon Aug 24 06:50:25 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Sun, 23 Aug 2020 23:50:25 -0700 Subject: [squeak-dev] Got FFI working on my own builds (production and debug) but downloaded all-in-one always never works In-Reply-To: References: <756E4228-4A03-46EF-8D55-AA9BFD6D56A8@cox.net> Message-ID: <93C632F1-116B-4393-A561-5B4AC7F17FED@cox.net> testing (sorry my email won’t send a real response) L From LEnglish5 at cox.net Mon Aug 24 06:52:18 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Sun, 23 Aug 2020 23:52:18 -0700 Subject: [squeak-dev] Got FFI working on my own builds (production and debug) but downloaded all-in-one always never works In-Reply-To: References: <756E4228-4A03-46EF-8D55-AA9BFD6D56A8@cox.net> Message-ID: <87878126-C699-404E-BF29-6FA1CE138F80@cox.net> >On Thu, Aug 20, 2020 at 1:56 PM LawsonEnglish wrote: >>So, with Craig Lattas help, I managed to build my own vm. I added back in the >>5.3-19435 image and changes files, and sources file, and changed the plist >>appropriately and it works just fine. >>Yay! >>However, I never did get the distributed version to work. I can sorta make it >>work with enough swapping of files, but it eventually crashes on startup even >>though FFI to my own dylib is working. >>The unmodified distributed 5.3 all-in-work apparently ALWAYS eventually >>crashes onstartup after trying to load a dylib and then staving, if I do it >>enough times, but thus far the ones I built do not do this. >If you run with an assert 5.3 VM build do you see anything indicative? And >are you saying that the 5.3 distribution also crashes on a recent VM? >>I can continue with my FFI experiments now (thanks everyone for their help), >>but unless something is very wrong with my Macs setup, the latst vesion of >>catalina isnt stable for FFI via dylib. _,,,^..^,,,_ best, Eliot From LEnglish5 at cox.net Mon Aug 24 06:57:14 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Sun, 23 Aug 2020 23:57:14 -0700 Subject: [squeak-dev] Got FFI working on my own builds (production and debug) but downloaded all-in-one always never works In-Reply-To: References: <756E4228-4A03-46EF-8D55-AA9BFD6D56A8@cox.net> Message-ID: This is another test (please disregard). L From LEnglish5 at cox.net Mon Aug 24 09:38:10 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Mon, 24 Aug 2020 02:38:10 -0700 Subject: [squeak-dev] Got FFI working on my own builds (production and debug) but downloaded all-in-one always never works In-Reply-To: References: <756E4228-4A03-46EF-8D55-AA9BFD6D56A8@cox.net> Message-ID: This is a test to see if there is still aproblem responding to Eliot’s message (my ISP wouldn’t let me respond directly but I could respond in private. If you can see this message, it means that the problem has corrected itself. L > On Aug 22, 2020, at 10:38 AM, Eliot Miranda wrote: > > Hi Lawson, > > On Thu, Aug 20, 2020 at 1:56 PM LawsonEnglish > wrote: > So, with Craig Latta’s help, I managed to build my own vm. I added back in the 5.3-19435 image and changes files, and sources file, and changed the plist appropriately and it works just fine. > > Yay! > > However, I never did get the distributed version to work. I can sorta make it work with enough swapping of files, but it eventually crashes on startup even though FFI to my own dylib is working. > > The unmodified distributed 5.3 all-in-work apparently ALWAYS eventually crashes onstartup after trying to load a dylib and then staving, if I do it enough times, but thus far the ones I built do not do this. > > If you run with an assert 5.3 VM build do you see anything indicative? And are you saying that the 5.3 distribution also crashes on a recent VM? > > I can continue with my FFI experiments now (thanks everyone for their help), but unless something is very wrong with my Mac’s setup, the latst vesion of catalina isn’t stable for FFI via dylib. > > > L > > _,,,^..^,,,_ > best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Mon Aug 24 10:14:17 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Mon, 24 Aug 2020 10:14:17 +0000 Subject: [squeak-dev] [BUG] Text drag and drop to workspace unreliable In-Reply-To: References: <2d1990eb9515419589eb10e97d48c105@student.hpi.uni-potsdam.de>, Message-ID: <361fcea836254b608153b3452edd0d0d@student.hpi.uni-potsdam.de> Thanks for the feedback! :-) Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Jakob Reschke Gesendet: Sonntag, 23. August 2020 13:48:00 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] [BUG] Text drag and drop to workspace unreliable Hi Christoph, After merging Morphic-ct.1675 and Morphic-ct.1676, it works as expected, thank you. Without ct.1676 the source workspace is not updated until it regains the keyboard focus, as described in the commit message. Kind regards, Jakob Am Do., 20. Aug. 2020 um 18:39 Uhr schrieb Thiede, Christoph : > > Hi Jakob, > > > does Morphic-ct.1675 resolve the issue for you? :-) > > > Best, > > Christoph > > ________________________________ > Von: Squeak-dev im Auftrag von Jakob Reschke > Gesendet: Sonntag, 29. Dezember 2019 21:40:19 > An: squeak-dev at lists.squeakfoundation.org > Betreff: [squeak-dev] [BUG] Text drag and drop to workspace unreliable > > Hi, > > I just noticed that the newly introduced text drag and drop sometimes does not work when dragging text between workspaces. It has always worked until today so I suspect the culprit is among the more recent changes. > > Problem: > When dragging the selected text from one workspace to another, sometimes an object reference is copied to the bindings of the workspace instead of pasting the text. In the target text, the newly created variable name appears instead (e. g. text3997962) as if I had dropped another non-text object. > > At least the text is not removed from the source workspace when this happens... > > Problem #2: > It does not always happen. When dragging from a third workspace it suddenly worked and then also from the second again. Then I reset my texts back to the old state and now it is broken again. > > Expected behavior: > The selected text from the source workspace is cut from there, and pasted at the drop hand location in the target workspace. > > Currently I have three workspaces #1, #2, #3. > If I drag the selection from #1 to #2, it works. > If I drag from #1 to #3 it does not. > Dragging from #2 to #3 does not work. > Dragging from #2 to #1 does work. > Now dragging from #1 to #3 suddenly does work... I dragged to the start of the text this time. > Dragging back from #3 to #1 works. > Dragging from #1 to #3 to the end of it also works. > Dragging back from #1 to #3. > Resetting (Cmd+l, lowercase L) text of #3. > Dragging from #1 to the end of #3 does not work again. Variable pasted at the start of the text. > Repeated dragging of the same text from #1 to #3 always pastes the variable. > Dragging to the middle of #3 works! > Dragging the pasted text inside of #3 to the end removed the text and pasted a variable instead. > > Hypothesis: it does not work to drop the text beyond the TextMorphForEditView. And so far I might just have been lucky to always have enough blank lines at the end of my target workspace. Workspaces #1 and #2 from above contain much more text than #3 and fill the whole editing area of the workspace, so this would be consistent. > > Squeak5.3beta > latest update: #19300 > > Kind regards, > Jakob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Mon Aug 24 10:15:03 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Mon, 24 Aug 2020 10:15:03 +0000 Subject: [squeak-dev] The Inbox: Morphic-ct.1677.mcz In-Reply-To: References: , Message-ID: <0df693ffd4454c8192ec93398eef571b@student.hpi.uni-potsdam.de> No problem. Thank you for reviewing the other commits! Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Eliot Miranda Gesendet: Sonntag, 23. August 2020 04:14:16 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1677.mcz Hi Christoph, I haven't copied this to trunk. not because it looks bad (it doesn't), but because I'm not qualified. Better someone who knows menus better than I does the integration. On Sat, Aug 22, 2020 at 10:35 AM > wrote: A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1677.mcz ==================== Summary ==================== Name: Morphic-ct.1677 Author: ct Time: 22 August 2020, 7:34:52.856555 pm UUID: 094ccc97-c3f6-364c-a10d-7418b3482703 Ancestors: Morphic-mt.1674 Nuke backward compatibility for Squeak 2.x menus. This should really not be relevant any longer I think. ;-) Also minor refactoring to MenuItemMorph >> #invokeWithEvent:. =============== Diff against Morphic-mt.1674 =============== Item was changed: ----- Method: MenuItemMorph>>invokeWithEvent: (in category 'events') ----- invokeWithEvent: evt "Perform the action associated with the given menu item." - | w | self isEnabled ifFalse: [^ self]. + + (owner notNil and: [self isStayUpItem not]) ifTrue: [ - target class == HandMorph ifTrue: [(self notObsolete) ifFalse: [^ self]]. - owner ifNotNil:[self isStayUpItem ifFalse:[ self flag: #workAround. "The tile system invokes menus straightforwardly so the menu might not be in the world." + self world ifNotNil: [:world | - (w := self world) ifNotNil:[ owner deleteIfPopUp: evt. "Repair damage before invoking the action for better feedback" + world displayWorldSafely]]. + + selector ifNil: [^ self]. + + Cursor normal showWhile: [ + "show cursor in case item opens a new MVC window" + selector numArgs isZero + ifTrue: [target perform: selector] + ifFalse: [target perform: selector withArguments: ( + selector numArgs = arguments size + ifTrue: [arguments] + ifFalse: [arguments copyWith: evt] )] ].! - w displayWorldSafely]]]. - selector ifNil:[^self]. - Cursor normal showWhile: [ | selArgCount | "show cursor in case item opens a new MVC window" - (selArgCount := selector numArgs) = 0 - ifTrue: - [target perform: selector] - ifFalse: - [selArgCount = arguments size - ifTrue: [target perform: selector withArguments: arguments] - ifFalse: [target perform: selector withArguments: (arguments copyWith: evt)]]].! Item was removed: - ----- Method: MenuItemMorph>>notObsolete (in category 'private') ----- - notObsolete - "Provide backward compatibility with messages being sent to the Hand. Remove this when no projects made prior to 2.9 are likely to be used. If this method is removed early, the worst that can happen is a notifier when invoking an item in an obsolete menu." - - (HandMorph canUnderstand: (selector)) ifTrue: [^ true]. "a modern one" - - self inform: 'This world menu is obsolete. - Please dismiss the menu and open a new one.'. - ^ false - ! -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Mon Aug 24 11:01:06 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Mon, 24 Aug 2020 11:01:06 +0000 Subject: [squeak-dev] Cannot reply on Nabble any longer Message-ID: <3494ce32ce334cd7b8b40c1b5ecfe439@student.hpi.uni-potsdam.de> Hi all, dear list admins, I cannot any longer reply to any message in the Nabble forum (http://forum.world.st/Squeak-Dev-f45488.html). If I open any thread and click "Reply", I get an "Authorized Users Only" error, but I am logged in with my account. In the past, this has worked fine. Could someone please reenable this feature? I found this very helpful because a) it allows me to reply to an old email that is not present in my own inbox, and b) I can format my messages in a way that is guaranteed to be displayed correctly in the mailing list archive. Best, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Mon Aug 24 11:26:55 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 24 Aug 2020 11:26:55 0000 Subject: [squeak-dev] The Inbox: Graphics-ct.437.mcz Message-ID: Christoph Thiede uploaded a new version of Graphics to project The Inbox: http://source.squeak.org/inbox/Graphics-ct.437.mcz ==================== Summary ==================== Name: Graphics-ct.437 Author: ct Time: 24 August 2020, 1:26:40.516818 pm UUID: 66c6c2fd-6978-6d43-8eda-c22f0a5defca Ancestors: Graphics-kfr.436 Proposal: Add Point >> #exactCenter:, complementing Graphics-cbc.372. Refine relevant method comments in Point and Rectangle. Usage example: m := Morph new. m changeProportionalLayout. n := Morph new. n color: Color red. m addMorph: n fullFrame: (LayoutFrame fractions: ( 0.5 @ 0.25 exactCenter: 0.5 @ 0.5)). m openInHand. =============== Diff against Graphics-kfr.436 =============== Item was changed: ----- Method: Point>>center: (in category 'converting to rectangle') ----- center: aPoint + "Answer a Rectangle whose extent is the receiver and whose center is approximately aPoint (after rounding to integers). This is one of the infix ways of expressing the creation of a rectangle." - "Answer a Rectangle whose extent is the receiver and whose center is - aPoint. This is one of the infix ways of expressing the creation of a - rectangle." + ^ Rectangle center: aPoint extent: self! - ^Rectangle center: aPoint extent: self! Item was added: + ----- Method: Point>>exactCenter: (in category 'converting to rectangle') ----- + exactCenter: aPoint + "Answer a Rectangle whose extent is the receiver and whose center is exactly aPoint. This is one of the infix ways of expressing the creation of a rectangle." + + ^ Rectangle exactCenter: aPoint extent: self! Item was changed: ----- Method: Rectangle class>>center:extent: (in category 'instance creation') ----- center: centerPoint extent: extentPoint + "Answer an instance of me whose center is approximately centerPoint (after rounding to integers) and whose extent is extentPoint." - "Answer an instance of me whose center is centerPoint and width - by height is extentPoint. " + ^ self origin: centerPoint - (extentPoint // 2) extent: extentPoint! - ^self origin: centerPoint - (extentPoint//2) extent: extentPoint! Item was changed: ----- Method: Rectangle class>>exactCenter:extent: (in category 'instance creation') ----- exactCenter: centerPoint extent: extentPoint + "Answer an instance of me whose center is exactly centerPoint and whose extent is extentPoint." + - "Answer an instance of me whose center is centerPoint and width - by height is extentPoint. " ^ self origin: centerPoint - (extentPoint / 2) extent: extentPoint ! From Christoph.Thiede at student.hpi.uni-potsdam.de Mon Aug 24 11:39:10 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Mon, 24 Aug 2020 11:39:10 +0000 Subject: [squeak-dev] The Inbox: Graphics-ct.437.mcz In-Reply-To: References: Message-ID: In particular, when it comes to LayoutFrames, I have to say that I find the automatic rounding behaviors of Point/Rectangle quite confusing. For instance, why does #scaleBy: allow producing float points/rectangles whereas #scaleFrom:to: applies rounding? In my opinion, the integer/float arithmetic of Point and Rectangle is not really clear. If these classes are intended containing integers only, the "truncation and round off" protocol would be redundant. If they are intended to contain floats as well, it is confusing that methods such as #center and #aboveCenter apply rounding. Would it be possible and wise to eliminate that automatic rounding behavior, or is too old and popular for such a breaking change? See also this related discussion: http://forum.world.st/The-Inbox-Graphics-cbc-372-mcz-td4940274.html Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von commits at source.squeak.org Gesendet: Montag, 24. August 2020 13:26:55 An: squeak-dev at lists.squeakfoundation.org Betreff: [squeak-dev] The Inbox: Graphics-ct.437.mcz Christoph Thiede uploaded a new version of Graphics to project The Inbox: http://source.squeak.org/inbox/Graphics-ct.437.mcz ==================== Summary ==================== Name: Graphics-ct.437 Author: ct Time: 24 August 2020, 1:26:40.516818 pm UUID: 66c6c2fd-6978-6d43-8eda-c22f0a5defca Ancestors: Graphics-kfr.436 Proposal: Add Point >> #exactCenter:, complementing Graphics-cbc.372. Refine relevant method comments in Point and Rectangle. Usage example: m := Morph new. m changeProportionalLayout. n := Morph new. n color: Color red. m addMorph: n fullFrame: (LayoutFrame fractions: ( 0.5 @ 0.25 exactCenter: 0.5 @ 0.5)). m openInHand. =============== Diff against Graphics-kfr.436 =============== Item was changed: ----- Method: Point>>center: (in category 'converting to rectangle') ----- center: aPoint + "Answer a Rectangle whose extent is the receiver and whose center is approximately aPoint (after rounding to integers). This is one of the infix ways of expressing the creation of a rectangle." - "Answer a Rectangle whose extent is the receiver and whose center is - aPoint. This is one of the infix ways of expressing the creation of a - rectangle." + ^ Rectangle center: aPoint extent: self! - ^Rectangle center: aPoint extent: self! Item was added: + ----- Method: Point>>exactCenter: (in category 'converting to rectangle') ----- + exactCenter: aPoint + "Answer a Rectangle whose extent is the receiver and whose center is exactly aPoint. This is one of the infix ways of expressing the creation of a rectangle." + + ^ Rectangle exactCenter: aPoint extent: self! Item was changed: ----- Method: Rectangle class>>center:extent: (in category 'instance creation') ----- center: centerPoint extent: extentPoint + "Answer an instance of me whose center is approximately centerPoint (after rounding to integers) and whose extent is extentPoint." - "Answer an instance of me whose center is centerPoint and width - by height is extentPoint. " + ^ self origin: centerPoint - (extentPoint // 2) extent: extentPoint! - ^self origin: centerPoint - (extentPoint//2) extent: extentPoint! Item was changed: ----- Method: Rectangle class>>exactCenter:extent: (in category 'instance creation') ----- exactCenter: centerPoint extent: extentPoint + "Answer an instance of me whose center is exactly centerPoint and whose extent is extentPoint." + - "Answer an instance of me whose center is centerPoint and width - by height is extentPoint. " ^ self origin: centerPoint - (extentPoint / 2) extent: extentPoint ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lecteur at zogotounga.net Mon Aug 24 12:25:12 2020 From: lecteur at zogotounga.net (=?UTF-8?Q?St=c3=a9phane_Rollandin?=) Date: Mon, 24 Aug 2020 14:25:12 +0200 Subject: [squeak-dev] The Inbox: Graphics-ct.437.mcz In-Reply-To: References: Message-ID: <3d88675e-5375-63c7-5e30-1f06c88d2896@zogotounga.net> > In my opinion, the integer/float arithmetic of Point and Rectangle is > not really clear Indeed. In my own images I have implemented #preciseCenter: and similar methods both in Pont and Rectangle to bypass rounding and work with floats. But I do not think that transitioning to an overall new convention (like getting rid of rounding altogether) is going to be safe. A lot of morphic code assumes that rectangles are always about pixels and expect their dimensions to be integers. Stef From commits at source.squeak.org Mon Aug 24 13:00:12 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 24 Aug 2020 13:00:12 0000 Subject: [squeak-dev] The Trunk: Graphics-pre.437.mcz Message-ID: Patrick Rein uploaded a new version of Graphics to project The Trunk: http://source.squeak.org/trunk/Graphics-pre.437.mcz ==================== Summary ==================== Name: Graphics-pre.437 Author: pre Time: 24 August 2020, 2:59:59.323786 pm UUID: 62f7d108-a88e-1e49-b109-11a9cc14b292 Ancestors: Graphics-kfr.436 Recategorizes a number of methods throughout the package to make categories more consistent. =============== Diff against Graphics-kfr.436 =============== Item was changed: + ----- Method: AbstractFont>>isRegular (in category 'testing') ----- - ----- Method: AbstractFont>>isRegular (in category 'accessing') ----- isRegular ^false! Item was changed: + ----- Method: Color>>= (in category 'comparing') ----- - ----- Method: Color>>= (in category 'equality') ----- = aColor "Return true if the receiver equals the given color. This method handles TranslucentColors, too." aColor isColor ifFalse: [^ false]. ^ aColor privateRGB = rgb and: [aColor privateAlpha = self privateAlpha] ! Item was changed: + ----- Method: Color>>diff: (in category 'comparing') ----- - ----- Method: Color>>diff: (in category 'equality') ----- diff: theOther "Returns a number between 0.0 and 1.0" ^ ((self privateRed - theOther privateRed) abs + (self privateGreen - theOther privateGreen) abs + (self privateBlue - theOther privateBlue) abs) / 3.0 / ComponentMax! Item was changed: + ----- Method: Color>>hash (in category 'comparing') ----- - ----- Method: Color>>hash (in category 'equality') ----- hash ^ rgb! Item was changed: + ----- Method: Color>>isBitmapFill (in category 'testing') ----- - ----- Method: Color>>isBitmapFill (in category 'queries') ----- isBitmapFill ^false! Item was changed: + ----- Method: Color>>isBlack (in category 'testing') ----- - ----- Method: Color>>isBlack (in category 'queries') ----- isBlack "Return true if the receiver represents black" ^rgb = 0! Item was changed: + ----- Method: Color>>isColor (in category 'testing') ----- - ----- Method: Color>>isColor (in category 'queries') ----- isColor ^ true ! Item was changed: + ----- Method: Color>>isGradientFill (in category 'testing') ----- - ----- Method: Color>>isGradientFill (in category 'queries') ----- isGradientFill ^false! Item was changed: + ----- Method: Color>>isGray (in category 'testing') ----- - ----- Method: Color>>isGray (in category 'queries') ----- isGray "Return true if the receiver represents a shade of gray" ^(self privateRed = self privateGreen) and:[self privateRed = self privateBlue]! Item was changed: + ----- Method: Color>>isOpaque (in category 'testing') ----- - ----- Method: Color>>isOpaque (in category 'queries') ----- isOpaque ^true! Item was changed: + ----- Method: Color>>isOrientedFill (in category 'testing') ----- - ----- Method: Color>>isOrientedFill (in category 'queries') ----- isOrientedFill "Return true if the receiver keeps an orientation (e.g., origin, direction, and normal)" ^false! Item was changed: + ----- Method: Color>>isSolidFill (in category 'testing') ----- - ----- Method: Color>>isSolidFill (in category 'queries') ----- isSolidFill ^true! Item was changed: + ----- Method: Color>>isTranslucent (in category 'testing') ----- - ----- Method: Color>>isTranslucent (in category 'queries') ----- isTranslucent ^ false ! Item was changed: + ----- Method: Color>>isTranslucentColor (in category 'testing') ----- - ----- Method: Color>>isTranslucentColor (in category 'queries') ----- isTranslucentColor "This means: self isTranslucent, but isTransparent not" ^ false! Item was changed: + ----- Method: Color>>isTransparent (in category 'testing') ----- - ----- Method: Color>>isTransparent (in category 'queries') ----- isTransparent ^ false ! Item was changed: + ----- Method: DisplayObject>>isTransparent (in category 'testing') ----- - ----- Method: DisplayObject>>isTransparent (in category 'displaying-Display') ----- isTransparent ^ false! Item was changed: + ----- Method: FormSetFont>>makeTintable (in category 'tinting') ----- - ----- Method: FormSetFont>>makeTintable (in category 'as yet unclassified') ----- makeTintable "Default." self tintable: true. self combinationRule: Form over.! Item was changed: + ----- Method: FormSetFont>>preserveColors (in category 'tinting') ----- - ----- Method: FormSetFont>>preserveColors (in category 'as yet unclassified') ----- preserveColors self tintable: false. self combinationRule: Form paint.! Item was changed: + ----- Method: FormSetFont>>preserveColorsWithAlpha (in category 'tinting') ----- - ----- Method: FormSetFont>>preserveColorsWithAlpha (in category 'as yet unclassified') ----- preserveColorsWithAlpha "Useful for rendering Emojis." self tintable: false. self combinationRule: Form blend.! Item was changed: + ----- Method: InfiniteForm>>asColor (in category 'converting') ----- - ----- Method: InfiniteForm>>asColor (in category 'accessing') ----- asColor ^ patternForm dominantColor! Item was changed: + ----- Method: InfiniteForm>>asForm (in category 'converting') ----- - ----- Method: InfiniteForm>>asForm (in category 'accessing') ----- asForm ^ patternForm! Item was changed: + ----- Method: Point>>isIntegerPoint (in category 'testing') ----- - ----- Method: Point>>isIntegerPoint (in category 'truncation and round off') ----- isIntegerPoint ^ x isInteger and: [ y isInteger ] ! Item was changed: + ----- Method: Point>>isPoint (in category 'testing') ----- - ----- Method: Point>>isPoint (in category 'converting') ----- isPoint ^ true! Item was changed: + ----- Method: Rectangle>>rightHalf (in category 'transforming') ----- - ----- Method: Rectangle>>rightHalf (in category 'truncation and round off') ----- rightHalf ^self withLeft: self center x! Item was changed: + ----- Method: TextStyle>>asStringOrText (in category 'converting') ----- - ----- Method: TextStyle>>asStringOrText (in category 'accessing') ----- asStringOrText "be fancy" ^ self defaultFont familyName asText addAttribute: (TextFontReference toFont: self defaultFont); yourself! Item was changed: + ----- Method: TextStyle>>printOn: (in category 'printing') ----- - ----- Method: TextStyle>>printOn: (in category 'accessing') ----- printOn: aStream super printOn: aStream. self defaultFont printShortDescriptionOn: aStream ! Item was changed: + ----- Method: TextStyle>>storeDataOn: (in category 'object from disk') ----- - ----- Method: TextStyle>>storeDataOn: (in category 'Disk I/O') ----- storeDataOn: aDataStream "The shared arrays in tabsArray and marginTabsArray are the globals DefaultTabsArray and DefaultMarginTabsArray. DiskProxies will be substituted for these in (Array objectForDataStream:)." ^ super storeDataOn: aDataStream! Item was changed: + ----- Method: TextStyle>>veryDeepCopyWith: (in category 'copying') ----- - ----- Method: TextStyle>>veryDeepCopyWith: (in category 'Disk I/O') ----- veryDeepCopyWith: deepCopier "All inst vars are meant to be shared" self == #veryDeepCopyWith:. "to satisfy checkVariables" ^ deepCopier references at: self ifAbsentPut: [self shallowCopy]. "remember"! Item was changed: + ----- Method: TranslucentColor>>hash (in category 'comparing') ----- - ----- Method: TranslucentColor>>hash (in category 'equality') ----- hash ^ rgb bitXor: alpha ! From commits at source.squeak.org Mon Aug 24 13:04:19 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 24 Aug 2020 13:04:19 0000 Subject: [squeak-dev] The Trunk: GraphicsTests-pre.55.mcz Message-ID: Patrick Rein uploaded a new version of GraphicsTests to project The Trunk: http://source.squeak.org/trunk/GraphicsTests-pre.55.mcz ==================== Summary ==================== Name: GraphicsTests-pre.55 Author: pre Time: 24 August 2020, 3:04:18.602786 pm UUID: 8459435a-1c95-9b46-a745-32f6d373c6a5 Ancestors: GraphicsTests-eem.54 Recategorizes methods throughout the package and improves two test cases which did only state the assertion in a comment. =============== Diff against GraphicsTests-eem.54 =============== Item was changed: + ----- Method: BMPReadWriterTest>>testBmp16Bit (in category 'tests') ----- - ----- Method: BMPReadWriterTest>>testBmp16Bit (in category 'reading') ----- testBmp16Bit | reader form | reader := BMPReadWriter new on: (ReadStream on: self bmpData16bit). form := reader nextImage. "special black here to compensate for zero-is-transparent effect" self assert: (form colorAt: 7 at 1) = Color red. self assert: (form colorAt: 1 at 7) = Color green. self assert: (form colorAt: 7 at 7) = Color blue. self assert: (form colorAt: 4 at 4) = Color white. self assert: (form pixelValueAt: 1 at 1) = 16r8000. ! Item was changed: + ----- Method: BMPReadWriterTest>>testBmp24Bit (in category 'tests') ----- - ----- Method: BMPReadWriterTest>>testBmp24Bit (in category 'reading') ----- testBmp24Bit | reader form | reader := BMPReadWriter new on: (ReadStream on: self bmpData24bit). form := reader nextImage. self assert: (form colorAt: 7 at 1) = Color red. self assert: (form colorAt: 1 at 7) = Color green. self assert: (form colorAt: 7 at 7) = Color blue. self assert: (form colorAt: 4 at 4) = Color white. self assert: (form pixelValueAt: 1 at 1) = 16rFF000001. ! Item was changed: + ----- Method: BMPReadWriterTest>>testBmp32Bit (in category 'tests') ----- - ----- Method: BMPReadWriterTest>>testBmp32Bit (in category 'reading') ----- testBmp32Bit | reader form | reader := BMPReadWriter new on: (ReadStream on: self bmpData32bit). form := reader nextImage. self assert: (form colorAt: 7 at 1) = Color red. self assert: (form colorAt: 1 at 7) = Color green. self assert: (form colorAt: 7 at 7) = Color blue. self assert: (form colorAt: 4 at 4) = Color white. self assert: (form pixelValueAt: 1 at 1) = 16rFF000000. ! Item was changed: + ----- Method: BMPReadWriterTest>>testBmp4Bit (in category 'tests') ----- - ----- Method: BMPReadWriterTest>>testBmp4Bit (in category 'reading') ----- testBmp4Bit | reader form | reader := BMPReadWriter new on: (ReadStream on: self bmpData4bit). form := reader nextImage. self assert: (form colorAt: 1 at 1) = Color black. self assert: (form colorAt: 7 at 1) = Color red. self assert: (form colorAt: 1 at 7) = Color green. self assert: (form colorAt: 7 at 7) = Color blue. self assert: (form colorAt: 4 at 4) = Color white. ! Item was changed: + ----- Method: BMPReadWriterTest>>testBmp8Bit (in category 'tests') ----- - ----- Method: BMPReadWriterTest>>testBmp8Bit (in category 'reading') ----- testBmp8Bit | reader form | reader := BMPReadWriter new on: (ReadStream on: self bmpData8bit). form := reader nextImage. self assert: (form colorAt: 1 at 1) = Color black. self assert: (form colorAt: 7 at 1) = Color red. self assert: (form colorAt: 1 at 7) = Color green. self assert: (form colorAt: 7 at 7) = Color blue. self assert: (form colorAt: 4 at 4) = Color white. ! Item was changed: + ----- Method: BitBltTest>>testAllAlphasRgbAdd (in category 'tests') ----- - ----- Method: BitBltTest>>testAllAlphasRgbAdd (in category 'bugs') ----- testAllAlphasRgbAdd "self run: #testAllAlphasRgbAdd" | sourceForm destForm blt correctAlphas | correctAlphas := 0. 0 to: 255 do: [:sourceAlpha | sourceForm := Form extent: 1 @ 1 depth: 32. sourceForm bits at: 1 put: sourceAlpha << 24 + (33 << 16) + (25 << 8) + 27. 0 to: 255 do: [:destAlpha | destForm := Form extent: 1 @ 1 depth: 32. destForm bits at: 1 put: destAlpha << 24 + (255 << 16) + (255 << 8) + 255. blt := BitBlt new. blt sourceForm: sourceForm. blt sourceOrigin: 0 @ 0. blt setDestForm: destForm. blt destOrigin: 0 @ 0. blt combinationRule: 20. "rgbAdd" blt copyBits. correctAlphas := correctAlphas + (((blt destForm bits at: 1) digitAt: 4) = (destAlpha + sourceAlpha min: 255) ifTrue: [1] ifFalse: [0]) ]]. self assert: 65536 equals: correctAlphas! Item was changed: + ----- Method: BitBltTest>>testAllAlphasRgbMax (in category 'tests') ----- - ----- Method: BitBltTest>>testAllAlphasRgbMax (in category 'bugs') ----- testAllAlphasRgbMax "self run: #testAllAlphasRgbMax" | sourceForm destForm blt correctAlphas | correctAlphas := 0. 0 to: 255 do: [:sourceAlpha | sourceForm := Form extent: 1 @ 1 depth: 32. sourceForm bits at: 1 put: sourceAlpha << 24 + (33 << 16) + (25 << 8) + 27. 0 to: 255 do: [:destAlpha | destForm := Form extent: 1 @ 1 depth: 32. destForm bits at: 1 put: destAlpha << 24 + (255 << 16) + (255 << 8) + 255. blt := BitBlt new. blt sourceForm: sourceForm. blt sourceOrigin: 0 @ 0. blt setDestForm: destForm. blt destOrigin: 0 @ 0. blt combinationRule: 27. "rgbMax" blt copyBits. correctAlphas := correctAlphas + (((blt destForm bits at: 1) digitAt: 4) = (destAlpha max: sourceAlpha) ifTrue: [1] ifFalse: [0]) ]]. self assert: 65536 equals: correctAlphas! Item was changed: + ----- Method: BitBltTest>>testAllAlphasRgbMin (in category 'tests') ----- - ----- Method: BitBltTest>>testAllAlphasRgbMin (in category 'bugs') ----- testAllAlphasRgbMin "self run: #testAllAlphasRgbMin" | sourceForm destForm blt correctAlphas | correctAlphas := 0. 0 to: 255 do: [:sourceAlpha | sourceForm := Form extent: 1 @ 1 depth: 32. sourceForm bits at: 1 put: sourceAlpha << 24 + (33 << 16) + (25 << 8) + 27. 0 to: 255 do: [:destAlpha | destForm := Form extent: 1 @ 1 depth: 32. destForm bits at: 1 put: destAlpha << 24 + (255 << 16) + (255 << 8) + 255. blt := BitBlt new. blt sourceForm: sourceForm. blt sourceOrigin: 0 @ 0. blt setDestForm: destForm. blt destOrigin: 0 @ 0. blt combinationRule: 28. "rgbMin" blt copyBits. correctAlphas := correctAlphas + (((blt destForm bits at: 1) digitAt: 4) = (destAlpha min: sourceAlpha) ifTrue: [1] ifFalse: [0]) ]]. self assert: 65536 equals: correctAlphas! Item was changed: + ----- Method: BitBltTest>>testAllAlphasRgbMinInvert (in category 'tests') ----- - ----- Method: BitBltTest>>testAllAlphasRgbMinInvert (in category 'bugs') ----- testAllAlphasRgbMinInvert "self run: #testAllAlphasRgbMinInvert" | sourceForm destForm blt correctAlphas | correctAlphas := 0. 0 to: 255 do: [:sourceAlpha | sourceForm := Form extent: 1 @ 1 depth: 32. sourceForm bits at: 1 put: sourceAlpha << 24 + (33 << 16) + (25 << 8) + 27. 0 to: 255 do: [:destAlpha | destForm := Form extent: 1 @ 1 depth: 32. destForm bits at: 1 put: destAlpha << 24 + (255 << 16) + (255 << 8) + 255. blt := BitBlt new. blt sourceForm: sourceForm. blt sourceOrigin: 0 @ 0. blt setDestForm: destForm. blt destOrigin: 0 @ 0. blt combinationRule: 29. "rgbMinInvert" blt copyBits. correctAlphas := correctAlphas + (((blt destForm bits at: 1) digitAt: 4) = (destAlpha min: 255-sourceAlpha) ifTrue: [1] ifFalse: [0]) ]]. self assert: 65536 equals: correctAlphas! Item was changed: + ----- Method: BitBltTest>>testAllAlphasRgbMul (in category 'tests') ----- - ----- Method: BitBltTest>>testAllAlphasRgbMul (in category 'bugs') ----- testAllAlphasRgbMul "self run: #testAllAlphasRgbMul" | sourceForm destForm blt correctAlphas | correctAlphas := 0. 0 to: 255 do: [:sourceAlpha | sourceForm := Form extent: 1 @ 1 depth: 32. sourceForm bits at: 1 put: sourceAlpha << 24 + (33 << 16) + (25 << 8) + 27. 0 to: 255 do: [:destAlpha | destForm := Form extent: 1 @ 1 depth: 32. destForm bits at: 1 put: destAlpha << 24 + (255 << 16) + (255 << 8) + 255. blt := BitBlt new. blt sourceForm: sourceForm. blt sourceOrigin: 0 @ 0. blt setDestForm: destForm. blt destOrigin: 0 @ 0. blt combinationRule: 37. "rgbMul" blt copyBits. correctAlphas := correctAlphas + (((blt destForm bits at: 1) digitAt: 4) = ((destAlpha+1) * (sourceAlpha+1)- 1 // 256) ifTrue: [1] ifFalse: [0]) ]]. self assert: 65536 equals: correctAlphas! Item was changed: + ----- Method: BitBltTest>>testAllAlphasRgbSub (in category 'tests') ----- - ----- Method: BitBltTest>>testAllAlphasRgbSub (in category 'bugs') ----- testAllAlphasRgbSub "self run: #testAllAlphasRgbSub" | sourceForm destForm blt correctAlphas | correctAlphas := 0. 0 to: 255 do: [:sourceAlpha | sourceForm := Form extent: 1 @ 1 depth: 32. sourceForm bits at: 1 put: sourceAlpha << 24 + (33 << 16) + (25 << 8) + 27. 0 to: 255 do: [:destAlpha | destForm := Form extent: 1 @ 1 depth: 32. destForm bits at: 1 put: destAlpha << 24 + (255 << 16) + (255 << 8) + 255. blt := BitBlt new. blt sourceForm: sourceForm. blt sourceOrigin: 0 @ 0. blt setDestForm: destForm. blt destOrigin: 0 @ 0. blt combinationRule: 21. "rgbSub" blt copyBits. correctAlphas := correctAlphas + (((blt destForm bits at: 1) digitAt: 4) = (destAlpha - sourceAlpha) abs ifTrue: [1] ifFalse: [0]) ]]. self assert: 65536 equals: correctAlphas! Item was changed: + ----- Method: BitBltTest>>testAlphaCompositing (in category 'tests') ----- - ----- Method: BitBltTest>>testAlphaCompositing (in category 'bugs') ----- testAlphaCompositing "self run: #testAlphaCompositing" | bb f1 f2 mixColor result eps | f1 := Form extent: 1 at 1 depth: 32. f2 := Form extent: 1 at 1 depth: 32. eps := 0.5 / 255. 0 to: 255 do:[:i| f1 colorAt: 0 at 0 put: Color blue. mixColor := Color red alpha: i / 255.0. f2 colorAt: 0 at 0 put: mixColor. mixColor := f2 colorAt: 0 at 0. bb := BitBlt toForm: f1. bb sourceForm: f2. bb combinationRule: Form blend. bb copyBits. result := f1 colorAt: 0 at 0. self assert: (result red - mixColor alpha) abs < eps. self assert: (result blue - (1.0 - mixColor alpha)) abs < eps. self assert: result alpha = 1.0. ].! Item was changed: + ----- Method: BitBltTest>>testAlphaCompositing2 (in category 'tests') ----- - ----- Method: BitBltTest>>testAlphaCompositing2 (in category 'bugs') ----- testAlphaCompositing2 "self run: #testAlphaCompositing2" | bb f1 f2 mixColor result eps | f1 := Form extent: 1 at 1 depth: 32. f2 := Form extent: 1 at 1 depth: 32. eps := 0.5 / 255. 0 to: 255 do:[:i| f1 colorAt: 0 at 0 put: Color transparent. mixColor := Color red alpha: i / 255.0. f2 colorAt: 0 at 0 put: mixColor. mixColor := f2 colorAt: 0 at 0. bb := BitBlt toForm: f1. bb sourceForm: f2. bb combinationRule: Form blend. bb copyBits. result := f1 colorAt: 0 at 0. self assert: (result red - mixColor alpha) abs < eps. self assert: result alpha = mixColor alpha. ].! Item was changed: + ----- Method: BitBltTest>>testPeekerUnhibernateBug (in category 'tests - bugs') ----- - ----- Method: BitBltTest>>testPeekerUnhibernateBug (in category 'bugs') ----- testPeekerUnhibernateBug "self run: #testPeekerUnhibernateBug" | bitBlt | bitBlt := BitBlt bitPeekerFromForm: Display. bitBlt destForm hibernate. "This should not throw an exception." + self + shouldnt: [bitBlt pixelAt: 1 at 1] + raise: Error! - bitBlt pixelAt: 1 at 1.! Item was changed: + ----- Method: BitBltTest>>testPivelValueAt (in category 'tests') ----- - ----- Method: BitBltTest>>testPivelValueAt (in category 'bugs') ----- testPivelValueAt "tests for the pixel peeking extension to bitBlt" " self run: #testPixelValueAt" |formList pixels | "make a Form of each depth" formList := #[1 2 4 8 16 32] collect:[:d| Form extent: 17 at 7 depth: d] as: Array. pixels := Dictionary new. pixels at: 1 put: 1; at: 2 put: 3; at:4 put: 7; at: 8 put: 16rFF; at: 16 put: 16rFFFF ; at: 32 put: 16rFFFFFFFF. "poke pixels to topleft (to test handling 0) bottomright (to test limits) middle (just because) peek at each location (to make sure it matches expectations)" formList do:[:f| |d pixval| d := f depth. pixval := pixels at: d. f pixelValueAt: 0 at 0 put: pixval. f pixelValueAt: 16 at 6 put: pixval. f pixelValueAt: 7 at 3 put: pixval. self assert: (f pixelValueAt: 0 at 0) = pixval. self assert: (f pixelValueAt: 1 at 0) = 0. self assert: (f pixelValueAt: 16 at 6) = pixval. self assert:(f pixelValueAt: 15 at 6) = 0. self assert: (f pixelValueAt: 7 at 3) = pixval. self assert: (f pixelValueAt: 6 at 3) = 0. ]! Item was changed: + ----- Method: BitBltTest>>testPokerUnhibernateBug (in category 'tests - bugs') ----- - ----- Method: BitBltTest>>testPokerUnhibernateBug (in category 'bugs') ----- testPokerUnhibernateBug "self run: #testPokerUnhibernateBug" | bitBlt | bitBlt := BitBlt bitPokerToForm: Display. bitBlt sourceForm hibernate. + self + shouldnt: [bitBlt pixelAt: 1 at 1 put: 0] + raise: Error.! - "This should not throw an exception." - bitBlt pixelAt: 1 at 1 put: 0.! Item was changed: + ----- Method: CharacterScannerTest>>testBreakAnywhere (in category 'tests') ----- - ----- Method: CharacterScannerTest>>testBreakAnywhere (in category 'testing') ----- testBreakAnywhere | p text cbs indicesOfM | text := ((String new: 2 withAll: $m) , (String space) , (String new: 2 withAll: $m)) asText. p := NewParagraph new. p compose: text style: style from: 1 in: (0 @ 0 corner: mWidth+1 @ (style lineGrid * 6)). indicesOfM := (1 to: text size) select: [:i | (text at: i) = $m]. self assert: p lines size equals: indicesOfM size description: 'Each m is on a new line'. self assert: (p lines collect: #first) equals: indicesOfM description: 'Each line begins with m'. cbs := indicesOfM collect: [:i | p characterBlockForIndex: i]. self assert: (cbs collect: #left as: Set) size = 1 description: 'Selecting before each m align on same column' ! Item was changed: + ----- Method: CharacterScannerTest>>testBreakAnywhereWhenFirstCharDoesNotFit (in category 'tests') ----- - ----- Method: CharacterScannerTest>>testBreakAnywhereWhenFirstCharDoesNotFit (in category 'testing') ----- testBreakAnywhereWhenFirstCharDoesNotFit | p text cbs | text := ((String new: 2 withAll: $m) , (String space) , (String new: 2 withAll: $m)) asText. p := NewParagraph new. p compose: text style: style from: 1 in: (0 @ 0 corner: mWidth-1 @ (style lineGrid * 7)). self assert: p lines size equals: text size + 1 description: 'Each character is on a new line, past end also'. self assert: (p lines collect: #first) equals: (1 to: text size + 1) asArray description: 'Each character is on a new line'. cbs := (1 to: text size + 1) collect: [:i | p characterBlockForIndex: i]. self assert: (cbs collect: #left as: Set) size = 1 description: 'Selecting before each character align on left' ! Item was changed: + ----- Method: CharacterScannerTest>>testBreakAtLastCr (in category 'tests') ----- - ----- Method: CharacterScannerTest>>testBreakAtLastCr (in category 'testing') ----- testBreakAtLastCr | p text cbfirst cblast cbend cbend2 | text := ((String new: 4 withAll: $m) , (String new: 2 withAll: Character space) , String cr) asText. p := NewParagraph new. p compose: text style: style from: 1 in: (0 @ 0 corner: mWidth*4+(spaceWidth*2)+1 @ (style lineGrid * 4)). self assert: p lines size = 2 description: 'An empty last line after CR must be materialized'. self assert: p lines first last = 7 description: 'The CR is included in the line preceding it'. cbfirst := p characterBlockForIndex: 1. cblast := p characterBlockForIndex: text size. self assert: cblast origin y = cbfirst origin y description: 'The CR coordinate is still on the first line'. cbend := p characterBlockForIndex: text size + 1. self assert: cbend origin y >= cblast corner y description: 'Past end is located on the next line'. cbend2 := p characterBlockAtPoint: 0 @ (cbend corner y + style lineGrid). self assert: cbend = cbend2 description: 'Clicking below the second line gives the past end location'. self assert: cbend origin = cbend2 origin. self assert: cbend corner = cbend2 corner. ! Item was changed: + ----- Method: CharacterScannerTest>>testBreakAtLastSpace (in category 'tests') ----- - ----- Method: CharacterScannerTest>>testBreakAtLastSpace (in category 'testing') ----- testBreakAtLastSpace | p text cbfirst cblast cbend cbend2 | text := ((String new: 4 withAll: $m) , (String new: 3 withAll: Character space)) asText. p := NewParagraph new. p compose: text style: style from: 1 in: (0 @ 0 corner: mWidth*4+(spaceWidth*2)+1 @ (style lineGrid * 4)). self assert: p lines size = 2 description: 'In leftFlush alignment, spaces at end of line overflowing the right margin should flow on next line'. self assert: p lines first last = 7 description: 'The space which is crossing the right margin is included in the first line as if it were a CR'. cbfirst := p characterBlockForIndex: 1. cblast := p characterBlockForIndex: text size. self assert: cblast origin y = cbfirst origin y description: 'The last space coordinate is still on the first line'. cbend := p characterBlockForIndex: text size + 1. self assert: cbend origin y >= cblast corner y description: 'Past end is located on the next line'. cbend2 := p characterBlockAtPoint: 0 @ (cbend corner y + style lineGrid). self assert: cbend = cbend2 description: 'Clicking below the second line gives the past end location'. self assert: cbend origin = cbend2 origin. self assert: cbend corner = cbend2 corner. ! Item was changed: + ----- Method: CharacterScannerTest>>testBreakAtSpace (in category 'tests') ----- - ----- Method: CharacterScannerTest>>testBreakAtSpace (in category 'testing') ----- testBreakAtSpace | p text cbfirst cblast cbend cbend2 | text := ((String new: 4 withAll: $m) , (String new: 4 withAll: Character space)) asText. p := NewParagraph new. p compose: text style: style from: 1 in: (0 @ 0 corner: mWidth*4+(spaceWidth*2)+1 @ (style lineGrid * 4)). self assert: p lines size = 2 description: 'In leftFlush alignment, spaces at end of line overflowing the right margin should flow on next line'. self assert: p lines first last = 7 description: 'The space which is crossing the right margin is included in the first line as if it were a CR'. cbfirst := p characterBlockForIndex: 1. cblast := p characterBlockForIndex: text size. self assert: cblast origin y >= cbfirst corner y description: 'The last space coordinate is under the first line'. cbend := p characterBlockForIndex: text size + 1. self assert: cbend origin x >= cblast corner x description: 'Past end is located right of last space'. cbend2 := p characterBlockAtPoint: 0 @ (cbend corner y + style lineGrid). self assert: cbend = cbend2 description: 'Clicking below the second line gives the past end location'. self assert: cbend origin = cbend2 origin. self assert: cbend corner = cbend2 corner. ! Item was changed: + ----- Method: CharacterScannerTest>>testBreakBeforeLongWord (in category 'tests') ----- - ----- Method: CharacterScannerTest>>testBreakBeforeLongWord (in category 'testing') ----- testBreakBeforeLongWord | p text cbfirst cblast cbend cbend2 cbend1 cbspace | text := ((String with: $m) , (String with: Character space) , (String new: 4 withAll: $m)) asText. p := NewParagraph new. p compose: text style: style from: 1 in: (0 @ 0 corner: mWidth*4+(spaceWidth*2)+1 @ (style lineGrid * 4)). self assert: p lines size = 2 description: 'In leftFlush alignment, a long word overflowing the right margin should flow on next line'. self assert: p lines first last = 2 description: 'The space before the long word is on the first line'. cbfirst := p characterBlockForIndex: 1. cblast := p characterBlockForIndex: text size. self assert: cblast origin y >= cbfirst corner y description: 'The long word coordinate is under the first line'. cbend := p characterBlockForIndex: text size + 1. self assert: cbend origin x >= cblast corner x description: 'Past end is located right of long word'. cbend2 := p characterBlockAtPoint: 0 @ (cbend corner y + style lineGrid). self assert: cbend = cbend2 description: 'Clicking below the second line gives the past end location'. self assert: cbend origin = cbend2 origin. self assert: cbend corner = cbend2 corner. cbspace := p characterBlockForIndex: 2. self assert: cbspace origin y = cbfirst origin y description: 'The space is on the first line'. cbend1 := p characterBlockAtPoint: cbspace corner x + 1 @ cbspace center y. self assert: cbend1 origin x >= cbspace corner x description: 'Clicking after the space starts right after the space'. self assert: cbend1 origin y = cbspace origin y description: 'Clicking after the space starts on same line as the space'. self assert: cbend1 stringIndex = 3 description: 'Clicking after the space starts on the long word'. ! Item was changed: + ----- Method: CharacterScannerTest>>testClickLeftOfCenteredText (in category 'tests') ----- - ----- Method: CharacterScannerTest>>testClickLeftOfCenteredText (in category 'testing') ----- testClickLeftOfCenteredText | p text cbfirst cbfirst2 | style := TextStyle default. mWidth := style defaultFont widthOf: $m. spaceWidth := style defaultFont widthOf: Character space. text := (String new: 4 withAll: $m) asText. text addAttribute: TextAlignment centered from: 1 to: text size. p := NewParagraph new. p compose: text style: style from: 1 in: (2 @ 2 extent: mWidth*8 @ (style lineGrid * 2)). cbfirst := p characterBlockForIndex: 1. cbfirst2 := p characterBlockAtPoint: 1 @ cbfirst center y. self assert: cbfirst = cbfirst2. self assert: cbfirst origin = cbfirst2 origin description: 'Clicking left of the margin shall position the cursor correctly'.! Item was changed: + ----- Method: RectangleTest>>testArea (in category 'tests') ----- - ----- Method: RectangleTest>>testArea (in category 'testing') ----- testArea | r1 empty | r1 := 0 at 0 extent: 10 at 20. self assert: r1 area = (10*20). self assert: (r1 translateBy: -20 at 10) area = (10*20) description: 'translation preserves area'. empty := 10 at 20 corner: 0 at 0. self assert: empty area = 0 description: 'the area of an empty rectangle is null'. empty := 10 at 0 corner: 0 at 20. self assert: empty area = 0 description: 'the area of an empty rectangle is null'. empty := 0 at 20 corner: 10 at 0. self assert: empty area = 0 description: 'the area of an empty rectangle is null'.! Item was changed: + ----- Method: RectangleTest>>testAreasOutside1 (in category 'tests') ----- - ----- Method: RectangleTest>>testAreasOutside1 (in category 'testing') ----- testAreasOutside1 "RectangleTest new testAreasOutside1" | frame rects visibleArea | frame := 0 at 0 extent: 300 at 300. rects := OrderedCollection new: 80. 0 to: 3 do: [:i | 0 to: 2 do: [:j | rects add: (i at j * 20 extent: 10 at 10) ] ]. visibleArea := Array with: frame. rects do: [:rect | | remnants | remnants := OrderedCollection new. visibleArea do: [:a | remnants addAll: (a areasOutside: rect)]. visibleArea := remnants. ]. visibleArea := visibleArea asArray. self assert: (visibleArea allSatisfy: [:r | r area ~= 0]). 1 to: visibleArea size do: [:idx | idx + 1 to: visibleArea size do: [:idx2 | self deny: ((visibleArea at: idx) intersects: (visibleArea at: idx2)). ] ]. 1 to: rects size do: [:idx | 1 to: visibleArea size do: [:idx2 | self deny: ((rects at: idx) intersects: (visibleArea at: idx2)). ] ]. ! Item was changed: + ----- Method: RectangleTest>>testAreasOutside2 (in category 'tests') ----- - ----- Method: RectangleTest>>testAreasOutside2 (in category 'testing') ----- testAreasOutside2 "RectangleTest new testAreasOutside2" | frame rects visibleArea | frame := 0 at 0 extent: 300 at 300. rects := OrderedCollection new: 80. rects add: (50 at 50 corner: 200 @ 200); add: (100 at 100 corner: 250 at 250). visibleArea := Array with: frame. rects do: [:rect | | remnants | remnants := OrderedCollection new. visibleArea do: [:a | remnants addAll: (a areasOutside: rect)]. visibleArea := remnants. ]. visibleArea := visibleArea asArray. self assert: (visibleArea allSatisfy: [:r | r area ~= 0]). 1 to: visibleArea size do: [:idx | idx + 1 to: visibleArea size do: [:idx2 | self deny: ((visibleArea at: idx) intersects: (visibleArea at: idx2)). ] ]. 1 to: rects size do: [:idx | 1 to: visibleArea size do: [:idx2 | self deny: ((rects at: idx) intersects: (visibleArea at: idx2)). ] ]. ! Item was changed: + ----- Method: RectangleTest>>testBottomHalf (in category 'tests') ----- - ----- Method: RectangleTest>>testBottomHalf (in category 'testing') ----- testBottomHalf | r | r := 10 at 20 corner: 30 at 50. self assert: (10 at 35 corner: 30 at 50) equals: r bottomHalf. self assert: (10 at 42 corner: 30 at 50) equals: r bottomHalf bottomHalf! Item was changed: + ----- Method: RectangleTest>>testBottomLeftQuadrant (in category 'tests') ----- - ----- Method: RectangleTest>>testBottomLeftQuadrant (in category 'testing') ----- testBottomLeftQuadrant | r | r := 10 at 20 corner: 30 at 50. self assert: (10 at 35 corner: 20 at 50) equals: r bottomLeftQuadrant. self assert: (10 at 42 corner: 15 at 50) equals: r bottomLeftQuadrant bottomLeftQuadrant! Item was changed: + ----- Method: RectangleTest>>testBottomRightQuadrant (in category 'tests') ----- - ----- Method: RectangleTest>>testBottomRightQuadrant (in category 'testing') ----- testBottomRightQuadrant | r | r := 10 at 20 corner: 30 at 50. self assert: (20 at 35 corner: 30 at 50) equals: r bottomRightQuadrant. self assert: (25 at 42 corner: 30 at 50) equals: r bottomRightQuadrant bottomRightQuadrant! Item was changed: + ----- Method: RectangleTest>>testCenter (in category 'tests') ----- - ----- Method: RectangleTest>>testCenter (in category 'testing') ----- testCenter | r1 c | r1 := 0 at 0 extent: 10 at 20. c := r1 center. self assert: (r1 containsPoint: c) description: 'the center is inside the rectangle'. self assert: (r1 topLeft dist: c) = (r1 bottomRight dist: c). self assert: (r1 bottomLeft dist: c) = (r1 topRight dist: c). self assert: (r1 topLeft dist: c) = (r1 bottomLeft dist: c). self assert: (r1 translateBy: -20 at 10) center = (c translateBy: -20 at 10) description: 'the center is translated with the rectangle'.! Item was changed: + ----- Method: RectangleTest>>testCenterEmpty (in category 'tests') ----- - ----- Method: RectangleTest>>testCenterEmpty (in category 'testing') ----- testCenterEmpty | r1 c | r1 := 30 at 10 corner: 10 at 20. c := r1 center. self deny: (r1 containsPoint: c) description: 'An empty rectangle does not contain any point.'. self assert: (r1 topLeft dist: c) = (r1 bottomRight dist: c). self assert: (r1 bottomLeft dist: c) = (r1 topRight dist: c). self assert: (r1 topLeft dist: c) = (r1 bottomLeft dist: c). self assert: (r1 translateBy: -20 at 10) center = (c translateBy: -20 at 10) description: 'the center is translated with the rectangle'.! Item was changed: + ----- Method: RectangleTest>>testCorner1 (in category 'tests') ----- - ----- Method: RectangleTest>>testCorner1 (in category 'testing') ----- testCorner1 "RectangleTest new testCorner1" | rect | rect := 10 at 10 extent: 20 at 30. self deny: (rect containsPoint: rect corner).! Item was changed: + ----- Method: RectangleTest>>testDegeneratedIntersectionTest (in category 'tests') ----- - ----- Method: RectangleTest>>testDegeneratedIntersectionTest (in category 'testing') ----- testDegeneratedIntersectionTest | horizontalLine verticalLine outsideRectangle | horizontalLine := 10 at 10 extent: 20 at 0. verticalLine := 20 at 0 extent: 0 at 20. self assert: (horizontalLine intersects: verticalLine). outsideRectangle := 100 at 10 extent: 20 at 20. self deny: (horizontalLine intersects: outsideRectangle).! Item was changed: + ----- Method: RectangleTest>>testFlip (in category 'tests') ----- - ----- Method: RectangleTest>>testFlip (in category 'testing') ----- testFlip | r1 c r1Horiz r1Vert | r1 := 30 at 10 extent: 10 at 20. c := 5 at 5. r1Horiz := r1 flipBy: #horizontal centerAt: c. r1Vert := r1 flipBy: #vertical centerAt: c. self assert: r1 area = r1Horiz area description: 'flip preserves area'. self assert: r1 area = r1Vert area description: 'flip preserves area'. self assert: r1 extent = r1Horiz extent description: 'flip preserves extent'. self assert: r1 extent = r1Vert extent description: 'flip preserves extent'. self assert: (r1 flipBy: #horizontal centerAt: r1 center) = r1. self assert: (r1 flipBy: #vertical centerAt: r1 center) = r1! Item was changed: + ----- Method: RectangleTest>>testFlipEmpty (in category 'tests') ----- - ----- Method: RectangleTest>>testFlipEmpty (in category 'testing') ----- testFlipEmpty | r1 c r1Horiz r1Vert | r1 := 30 at 10 corner: 10 at 20. c := 5 at 5. r1Horiz := r1 flipBy: #horizontal centerAt: c. r1Vert := r1 flipBy: #vertical centerAt: c. self assert: r1 area = r1Horiz area description: 'flip preserves area'. self assert: r1 area = r1Vert area description: 'flip preserves area'. self assert: r1 extent = r1Horiz extent description: 'flip preserves extent'. self assert: r1 extent = r1Vert extent description: 'flip preserves extent'. self assert: (r1 flipBy: #horizontal centerAt: r1 center) = r1. self assert: (r1 flipBy: #vertical centerAt: r1 center) = r1! Item was changed: + ----- Method: RectangleTest>>testIntersection1 (in category 'tests') ----- - ----- Method: RectangleTest>>testIntersection1 (in category 'testing') ----- testIntersection1 "RectangleTest new testIntersection1" | rect1 rect2 | rect1 := 10 at 10 corner: 20 at 30. rect2 := rect1 corner extent: 20 at 40. self deny: (rect1 intersects: rect2).! Item was changed: + ----- Method: RectangleTest>>testIntersection2 (in category 'tests') ----- - ----- Method: RectangleTest>>testIntersection2 (in category 'testing') ----- testIntersection2 "RectangleTest new testIntersection2" | rect1 rect2 | rect1 := 0 at 0 corner: 40 at 40. rect2 := 40 at 40 corner: 50 at 50. self deny: (rect1 intersects: rect2); deny: (rect2 intersects: rect1).! Item was changed: + ----- Method: RectangleTest>>testIntersectionEmpty (in category 'tests') ----- - ----- Method: RectangleTest>>testIntersectionEmpty (in category 'testing') ----- testIntersectionEmpty | rect1 empty1 empty2 | rect1 := 10 at 10 corner: 40 at 40. empty1 := 50 at 50 corner: 0 at 0. empty2 := 30 at 30 corner: 20 at 20. self deny: (rect1 intersects: empty1); deny: (rect1 intersects: empty2); deny: (empty1 intersects: rect1); deny: (empty2 intersects: rect1); deny: (empty1 intersects: empty2); deny: (empty2 intersects: empty1).! Item was changed: + ----- Method: RectangleTest>>testLeftHalf (in category 'tests') ----- - ----- Method: RectangleTest>>testLeftHalf (in category 'testing') ----- testLeftHalf | r | r := 10 at 20 corner: 30 at 50. self assert: (10 at 20 corner: 20 at 50) equals: r leftHalf. self assert: (10 at 20 corner: 15 at 50) equals: r leftHalf leftHalf! Item was changed: + ----- Method: RectangleTest>>testRightHalf (in category 'tests') ----- - ----- Method: RectangleTest>>testRightHalf (in category 'testing') ----- testRightHalf | r | r := 10 at 20 corner: 30 at 50. self assert: (20 at 20 corner: 30 at 50) equals: r rightHalf. self assert: (25 at 20 corner: 30 at 50) equals: r rightHalf rightHalf! Item was changed: + ----- Method: RectangleTest>>testRotate (in category 'tests') ----- - ----- Method: RectangleTest>>testRotate (in category 'testing') ----- testRotate | r1 c r1Left r1Right r1Pi | r1 := 30 at 10 extent: 10 at 20. c := 5 at 5. r1Left := r1 rotateBy: #left centerAt: c. r1Right := r1 rotateBy: #right centerAt: c. r1Pi := r1 rotateBy: #pi centerAt: c. self assert: r1 area = r1Left area description: 'rotation preserves area'. self assert: r1 area = r1Right area description: 'rotation preserves area'. self assert: r1 area = r1Pi area description: 'rotation preserves area'. self assert: r1 extent transposed = r1Left extent. self assert: r1 extent transposed = r1Right extent. self assert: r1 extent = r1Pi extent. self assert: (r1 rotateBy: #pi centerAt: r1 center) = r1! Item was changed: + ----- Method: RectangleTest>>testRotateEmpty (in category 'tests') ----- - ----- Method: RectangleTest>>testRotateEmpty (in category 'testing') ----- testRotateEmpty | r1 c r1Left r1Right r1Pi | r1 := 30 at 10 corner: 10 at 20. c := 5 at 5. r1Left := r1 rotateBy: #left centerAt: c. r1Right := r1 rotateBy: #right centerAt: c. r1Pi := r1 rotateBy: #pi centerAt: c. self assert: r1 area = r1Left area description: 'rotation preserves area'. self assert: r1 area = r1Right area description: 'rotation preserves area'. self assert: r1 area = r1Pi area description: 'rotation preserves area'. self assert: r1 extent transposed = r1Left extent. self assert: r1 extent transposed = r1Right extent. self assert: r1 extent = r1Pi extent. self assert: (r1 rotateBy: #pi centerAt: r1 center) = r1! Item was changed: + ----- Method: RectangleTest>>testTopHalf (in category 'tests') ----- - ----- Method: RectangleTest>>testTopHalf (in category 'testing') ----- testTopHalf | r | r := 10 at 20 corner: 30 at 50. self assert: (10 at 20 corner: 30 at 35) equals: r topHalf. self assert: (10 at 20 corner: 30 at 27) equals: r topHalf topHalf! Item was changed: + ----- Method: RectangleTest>>testTopLeftQuadrant (in category 'tests') ----- - ----- Method: RectangleTest>>testTopLeftQuadrant (in category 'testing') ----- testTopLeftQuadrant | r | r := 10 at 20 corner: 30 at 50. self assert: (10 at 20 corner: 20 at 35) equals: r topLeftQuadrant. self assert: (10 at 20 corner: 15 at 27) equals: r topLeftQuadrant topLeftQuadrant! Item was changed: + ----- Method: RectangleTest>>testTopRightQuadrant (in category 'tests') ----- - ----- Method: RectangleTest>>testTopRightQuadrant (in category 'testing') ----- testTopRightQuadrant | r | r := 10 at 20 corner: 30 at 50. self assert: (20 at 20 corner: 30 at 35) equals: r topRightQuadrant. self assert: (25 at 20 corner: 30 at 27) equals: r topRightQuadrant topRightQuadrant! From commits at source.squeak.org Mon Aug 24 13:13:32 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 24 Aug 2020 13:13:32 0000 Subject: [squeak-dev] The Trunk: SUnit-pre.122.mcz Message-ID: Patrick Rein uploaded a new version of SUnit to project The Trunk: http://source.squeak.org/trunk/SUnit-pre.122.mcz ==================== Summary ==================== Name: SUnit-pre.122 Author: pre Time: 24 August 2020, 3:13:32.049786 pm UUID: 6755fd5f-c8d9-b94b-b7ce-61cb56b0de2e Ancestors: SUnit-mt.121 Recateogrizes assertions and timeout infrastructure from the "accessing" category to their own method categories. =============== Diff against SUnit-mt.121 =============== Item was changed: + ----- Method: TestCase>>assert: (in category 'asserting') ----- - ----- Method: TestCase>>assert: (in category 'accessing') ----- assert: aBooleanOrBlock aBooleanOrBlock value ifFalse: [self signalFailure: 'Assertion failed'] ! Item was changed: + ----- Method: TestCase>>assert:description: (in category 'asserting') ----- - ----- Method: TestCase>>assert:description: (in category 'accessing') ----- assert: aBooleanOrBlock description: aStringOrBlock aBooleanOrBlock value ifFalse: [ | description | description := aStringOrBlock value. self logFailure: description. TestResult failure signal: description ] ! Item was changed: + ----- Method: TestCase>>assert:description:resumable: (in category 'asserting') ----- - ----- Method: TestCase>>assert:description:resumable: (in category 'accessing') ----- assert: aBooleanOrBlock description: aString resumable: resumableBoolean | exception | aBooleanOrBlock value ifFalse: [self logFailure: aString. exception := resumableBoolean ifTrue: [TestResult resumableFailure] ifFalse: [TestResult failure]. exception signal: aString] ! Item was changed: + ----- Method: TestCase>>assert:equals: (in category 'asserting') ----- - ----- Method: TestCase>>assert:equals: (in category 'accessing') ----- assert: expected equals: actual ^self assert: expected = actual description: [ self comparingStringBetween: expected and: actual ] ! Item was changed: + ----- Method: TestCase>>assert:equals:description: (in category 'asserting') ----- - ----- Method: TestCase>>assert:equals:description: (in category 'accessing') ----- assert: expected equals: actual description: aString ^self assert: expected = actual description: [ aString , ': ', (self comparingStringBetween: expected and: actual) ]! Item was changed: + ----- Method: TestCase>>assert:identical: (in category 'asserting') ----- - ----- Method: TestCase>>assert:identical: (in category 'accessing') ----- assert: expected identical: actual ^self assert: expected == actual description: [ self comparingStringBetweenIdentical: expected and: actual ] ! Item was changed: + ----- Method: TestCase>>assert:identical:description: (in category 'asserting') ----- - ----- Method: TestCase>>assert:identical:description: (in category 'accessing') ----- assert: expected identical: actual description: aString ^self assert: expected == actual description: [ aString , ': ', (self comparingStringBetweenIdentical: expected and: actual) ]! Item was changed: + ----- Method: TestCase>>defaultTimeout (in category 'running - timeout') ----- - ----- Method: TestCase>>defaultTimeout (in category 'accessing') ----- defaultTimeout "Answer the default timeout to use for tests in this test case. The timeout is a value in seconds." ^Smalltalk isLowerPerformance ifTrue:[ 25] ifFalse: [5] "seconds"! Item was changed: + ----- Method: TestCase>>deny: (in category 'asserting') ----- - ----- Method: TestCase>>deny: (in category 'accessing') ----- deny: aBooleanOrBlock self assert: aBooleanOrBlock value not ! Item was changed: + ----- Method: TestCase>>deny:description: (in category 'asserting') ----- - ----- Method: TestCase>>deny:description: (in category 'accessing') ----- deny: aBooleanOrBlock description: aString self assert: aBooleanOrBlock value not description: aString ! Item was changed: + ----- Method: TestCase>>deny:description:resumable: (in category 'asserting') ----- - ----- Method: TestCase>>deny:description:resumable: (in category 'accessing') ----- deny: aBooleanOrBlock description: aString resumable: resumableBoolean self assert: aBooleanOrBlock value not description: aString resumable: resumableBoolean ! Item was changed: + ----- Method: TestCase>>deny:equals: (in category 'asserting') ----- - ----- Method: TestCase>>deny:equals: (in category 'accessing') ----- deny: unexpected equals: actual ^self deny: unexpected = actual description: 'Actual equals unexpected' ! Item was changed: + ----- Method: TestCase>>ensureInternetConnection (in category 'asserting - extensions') ----- - ----- Method: TestCase>>ensureInternetConnection (in category 'extensions') ----- ensureInternetConnection ^ self ensureInternetConnectionTo: 'http://www.google.com'! Item was changed: + ----- Method: TestCase>>ensureInternetConnectionTo: (in category 'asserting - extensions') ----- - ----- Method: TestCase>>ensureInternetConnectionTo: (in category 'extensions') ----- ensureInternetConnectionTo: url "(Smalltalk classNamed: 'WebClient') httpGet: 'http://www.google.com'" ((Smalltalk classNamed: 'WebClient') httpGet: url) isSuccess ifFalse: [Error signal: 'No internet connection available, but test requires one'] ! Item was changed: + ----- Method: TestCase>>ensureSecureInternetConnection (in category 'asserting - extensions') ----- - ----- Method: TestCase>>ensureSecureInternetConnection (in category 'extensions') ----- ensureSecureInternetConnection ^ self ensureInternetConnectionTo: 'https://www.google.com'! Item was changed: + ----- Method: TestCase>>executeShould:inScopeOf:withExceptionDo: (in category 'asserting - extensions') ----- - ----- Method: TestCase>>executeShould:inScopeOf:withExceptionDo: (in category 'extensions') ----- executeShould: aBlock inScopeOf: anException withExceptionDo: anotherBlock ^[aBlock value. false] on: anException do: [:exception | anotherBlock value: exception. exception return: true]! Item was changed: + ----- Method: TestCase>>fail (in category 'asserting - extensions') ----- - ----- Method: TestCase>>fail (in category 'extensions') ----- fail ^self assert: false! Item was changed: + ----- Method: TestCase>>fail: (in category 'asserting - extensions') ----- - ----- Method: TestCase>>fail: (in category 'extensions') ----- fail: aString ^self assert: false description: aString.! Item was changed: + ----- Method: TestCase>>should: (in category 'asserting') ----- - ----- Method: TestCase>>should: (in category 'accessing') ----- should: aBlock self assert: aBlock value ! Item was changed: + ----- Method: TestCase>>should:description: (in category 'asserting') ----- - ----- Method: TestCase>>should:description: (in category 'accessing') ----- should: aBlock description: aString self assert: aBlock value description: aString ! Item was changed: + ----- Method: TestCase>>should:notTakeMoreThan: (in category 'asserting - extensions') ----- - ----- Method: TestCase>>should:notTakeMoreThan: (in category 'extensions') ----- should: aBlock notTakeMoreThan: aDuration "Evaluate aBlock in a forked process and if it takes more than anInteger milliseconds to run we terminate the process and report a test failure. It'' important to use the active process for the test failure so that the failure reporting works correctly in the context of the exception handlers." | evaluated evaluationProcess result delay testProcess | evaluated := false. delay := Delay forDuration: aDuration. testProcess := Processor activeProcess. "Create a new process to evaluate aBlock" evaluationProcess := [ result := aBlock value. evaluated := true. delay unschedule. testProcess resume ] forkNamed: 'Process to evaluate should: notTakeMoreThanMilliseconds:'. "Wait the milliseconds they asked me to" delay wait. "After this point either aBlock was evaluated or not..." evaluated ifFalse: [ evaluationProcess terminate. self assert: false description: ('Block evaluation took more than the expected <1p>' expandMacrosWith: aDuration)]. ^result! Item was changed: + ----- Method: TestCase>>should:notTakeMoreThanMilliseconds: (in category 'asserting - extensions') ----- - ----- Method: TestCase>>should:notTakeMoreThanMilliseconds: (in category 'extensions') ----- should: aBlock notTakeMoreThanMilliseconds: anInteger "For compatibility with other Smalltalks" self should: aBlock notTakeMoreThan: (Duration milliSeconds: anInteger).! Item was changed: + ----- Method: TestCase>>should:raise: (in category 'asserting') ----- - ----- Method: TestCase>>should:raise: (in category 'accessing') ----- should: aBlock raise: anExceptionalEvent ^self assert: (self executeShould: aBlock inScopeOf: anExceptionalEvent) ! Item was changed: + ----- Method: TestCase>>should:raise:description: (in category 'asserting') ----- - ----- Method: TestCase>>should:raise:description: (in category 'accessing') ----- should: aBlock raise: anExceptionalEvent description: aString ^self assert: (self executeShould: aBlock inScopeOf: anExceptionalEvent) description: aString ! Item was changed: + ----- Method: TestCase>>should:raise:whoseDescriptionDoesNotInclude:description: (in category 'asserting') ----- - ----- Method: TestCase>>should:raise:whoseDescriptionDoesNotInclude:description: (in category 'accessing') ----- should: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString ^self assert: (self executeShould: aBlock inScopeOf: anExceptionalEvent withDescriptionNotContaining: subString) description: aString ! Item was changed: + ----- Method: TestCase>>should:raise:whoseDescriptionIncludes:description: (in category 'asserting') ----- - ----- Method: TestCase>>should:raise:whoseDescriptionIncludes:description: (in category 'accessing') ----- should: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString ^self assert: (self executeShould: aBlock inScopeOf: anExceptionalEvent withDescriptionContaining: subString) description: aString ! Item was changed: + ----- Method: TestCase>>should:raise:withExceptionDo: (in category 'asserting - extensions') ----- - ----- Method: TestCase>>should:raise:withExceptionDo: (in category 'extensions') ----- should: aBlock raise: anException withExceptionDo: anotherBlock ^self assert: (self executeShould: aBlock inScopeOf: anException withExceptionDo: anotherBlock)! Item was changed: + ----- Method: TestCase>>shouldFix: (in category 'asserting - extensions') ----- - ----- Method: TestCase>>shouldFix: (in category 'extensions') ----- shouldFix: aBlock ^self should: aBlock raise: Exception! Item was changed: + ----- Method: TestCase>>shouldnt: (in category 'asserting') ----- - ----- Method: TestCase>>shouldnt: (in category 'accessing') ----- shouldnt: aBlock self deny: aBlock value ! Item was changed: + ----- Method: TestCase>>shouldnt:description: (in category 'asserting') ----- - ----- Method: TestCase>>shouldnt:description: (in category 'accessing') ----- shouldnt: aBlock description: aString self deny: aBlock value description: aString ! Item was changed: + ----- Method: TestCase>>shouldnt:raise: (in category 'asserting') ----- - ----- Method: TestCase>>shouldnt:raise: (in category 'accessing') ----- shouldnt: aBlock raise: anExceptionalEvent ^ [ aBlock value ] on: anExceptionalEvent do: [:e | self fail: 'Block raised ', e className, ': ', e messageText].! Item was changed: + ----- Method: TestCase>>shouldnt:raise:description: (in category 'asserting') ----- - ----- Method: TestCase>>shouldnt:raise:description: (in category 'accessing') ----- shouldnt: aBlock raise: anExceptionalEvent description: aString ^self assert: (self executeShould: aBlock inScopeOf: anExceptionalEvent) not description: aString ! Item was changed: + ----- Method: TestCase>>shouldnt:raise:whoseDescriptionDoesNotInclude:description: (in category 'asserting') ----- - ----- Method: TestCase>>shouldnt:raise:whoseDescriptionDoesNotInclude:description: (in category 'accessing') ----- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString ^self assert: (self executeShould: aBlock inScopeOf: anExceptionalEvent withDescriptionNotContaining: subString) not description: aString ! Item was changed: + ----- Method: TestCase>>shouldnt:raise:whoseDescriptionIncludes:description: (in category 'asserting') ----- - ----- Method: TestCase>>shouldnt:raise:whoseDescriptionIncludes:description: (in category 'accessing') ----- shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString ^self assert: (self executeShould: aBlock inScopeOf: anExceptionalEvent withDescriptionContaining: subString) not description: aString ! Item was changed: + ----- Method: TestCase>>signalFailure: (in category 'private') ----- - ----- Method: TestCase>>signalFailure: (in category 'accessing') ----- signalFailure: aString TestResult failure signal: aString! Item was changed: + ----- Method: TestCase>>timeout: (in category 'running - timeout') ----- - ----- Method: TestCase>>timeout: (in category 'accessing') ----- timeout: seconds "The timeout for a test should normally be set with a method annotation. However, for tests that are expected to run in images that do not support method annotations, the value may be set by setting the value from the #setUp method (i.e. prior to running the test method)." timeout := seconds! Item was changed: + ----- Method: TestCase>>timeout:after: (in category 'private') ----- - ----- Method: TestCase>>timeout:after: (in category 'running') ----- timeout: aBlock after: seconds "Evaluate the argument block. Time out if the evaluation is not complete after the given number of seconds. Handle the situation that a timeout may occur after a failure (during debug)" | theProcess delay watchdog | "the block will be executed in the current process" theProcess := Processor activeProcess. delay := Delay forSeconds: seconds. "make a watchdog process" watchdog := [ delay wait. "wait for timeout or completion" theProcess ifNotNil:[ theProcess signalException: (TestFailure new messageText: 'Test timed out') ] ] newProcess. "Watchdog needs to run at high priority to do its job (but not at timing priority)" watchdog priority: Processor timingPriority-1. "catch the timeout signal" watchdog resume. "start up the watchdog" ^[aBlock on: TestFailure, Error, Halt do:[:ex| theProcess := nil. ex pass. ]] ensure:[ "evaluate the receiver" theProcess := nil. "it has completed, so ..." delay delaySemaphore signal. "arrange for the watchdog to exit" ]! Item was changed: + ----- Method: TestCase>>timeoutForSetUp (in category 'running - timeout') ----- - ----- Method: TestCase>>timeoutForSetUp (in category 'accessing') ----- timeoutForSetUp "Answer the timeout to use for setUp" | method | method := self class lookupSelector: testSelector asSymbol. (method pragmaAt: #timeout:) ifNotNil:[:tag| ^tag arguments first]. ^self defaultTimeout! Item was changed: + ----- Method: TestCase>>timeoutForTest (in category 'running - timeout') ----- - ----- Method: TestCase>>timeoutForTest (in category 'accessing') ----- timeoutForTest "Answer the timeout to use for this test" | method | method := self class lookupSelector: testSelector asSymbol. (method pragmaAt: #timeout:) ifNotNil:[:tag| ^tag arguments first]. ^timeout ifNil: [self defaultTimeout]! From builds at travis-ci.org Mon Aug 24 14:55:33 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 24 Aug 2020 14:55:33 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1804 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f43d4e5227c3_13fe0e054def830451f@travis-tasks-546f689556-5c92w.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1804 Status: Errored Duration: 17 mins and 35 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/720665540?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at usmedrec.com Mon Aug 24 15:21:36 2020 From: ron at usmedrec.com (Ron Teitelbaum) Date: Mon, 24 Aug 2020 11:21:36 -0400 Subject: [squeak-dev] test In-Reply-To: <0F8239BB-08B2-4B6C-81CC-2A4DECC576E9@cox.net> References: <756E4228-4A03-46EF-8D55-AA9BFD6D56A8@cox.net> <0F8239BB-08B2-4B6C-81CC-2A4DECC576E9@cox.net> Message-ID: ack On Mon, Aug 24, 2020 at 2:49 AM LawsonEnglish wrote: > test > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at clipperadams.com Mon Aug 24 18:12:58 2020 From: sean at clipperadams.com (Sean P. DeNigris) Date: Mon, 24 Aug 2020 13:12:58 -0500 (CDT) Subject: [squeak-dev] Git and Tonel (and Magritte) Message-ID: <1598292778081-0.post@n4.nabble.com> We would like to port Magritte to Tonel because we have reports of problems on Windows with long filenames and would like to understand the ramifications to users. Three questions: 1. Do any Squeakers load Magritte from https://github.com/magritte-metamodel/magritte ? 2. Does Squeak support git? 3. Does Squeak support Tonel? I found references to 2 and 3 in this ML, but nothing definitive. I'm generally interested in those answers beyond the current porting effort. In short, will anyone be disrupted by the proposed migration? Thanks ----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From sean at clipperadams.com Mon Aug 24 18:15:18 2020 From: sean at clipperadams.com (Sean P. DeNigris) Date: Mon, 24 Aug 2020 13:15:18 -0500 (CDT) Subject: [squeak-dev] Cannot reply on Nabble any longer In-Reply-To: <3494ce32ce334cd7b8b40c1b5ecfe439@student.hpi.uni-potsdam.de> References: <3494ce32ce334cd7b8b40c1b5ecfe439@student.hpi.uni-potsdam.de> Message-ID: <1598292918680-0.post@n4.nabble.com> I don't know why it changed, but we had the same problem with the Pharo lists. I applied the same fix to Squeak Dev. Let me know if it works now. ----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From commits at source.squeak.org Mon Aug 24 18:22:33 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Mon, 24 Aug 2020 18:22:33 0000 Subject: [squeak-dev] The Inbox: EToys-ct.402.mcz Message-ID: Christoph Thiede uploaded a new version of EToys to project The Inbox: http://source.squeak.org/inbox/EToys-ct.402.mcz ==================== Summary ==================== Name: EToys-ct.402 Author: ct Time: 24 August 2020, 8:22:21.479269 pm UUID: 8b6598bf-158f-a74f-a399-f82c39269bdc Ancestors: EToys-eem.400 Fixes EToys fences for players within flexshells by subtracting transformations. =============== Diff against EToys-eem.400 =============== Item was changed: ----- Method: Player>>forward: (in category 'scripts-standard') ----- forward: dist "Move forward (viz. in the direction of my heading) by the given amount" | rho radians delta didStray p aCostume aPlayfield | (aCostume := self costume) isInWorld ifFalse: [^ self]. aCostume isWorldOrHandMorph ifTrue: [^ self]. aCostume owner isHandMorph ifTrue: [^ self]. + - rho := (aCostume asNumber: dist) asFloat. + radians := (self getHeadingUnrounded asFloat - 90) degreesToRadians. - radians := (self getHeadingUnrounded asFloat - 90.0) degreesToRadians. delta := (radians cos @ radians sin) * rho. + + (aPlayfield := aCostume pasteUpMorph) fenceEnabled ifTrue: [ + | playfieldBounds costumeBounds | + playfieldBounds := aPlayfield boundsInWorld. + costumeBounds := aCostume boundsInWorld. + (playfieldBounds containsRect: costumeBounds) ifFalse: [ + "If I stray out of the bounds of my playfield, pull me back, but without changing my heading as bounce would. Do nothing if bounce has already corrected the direction." - - (aPlayfield := aCostume pasteUpMorph) fenceEnabled ifTrue: - [(aPlayfield bounds containsRect: aCostume bounds) ifFalse: - ["If I stray out of the bounds of my playfield, pull me back, but - without changing my heading as bounce would. Do nothing if - bounce has already corrected the direction." didStray := false. + ((costumeBounds left < playfieldBounds left and: [delta x < 0]) + or: [costumeBounds right > playfieldBounds right and: [delta x > 0]]) + ifTrue: [ + delta := delta x negated @ delta y. + didStray := true]. + ((costumeBounds top < playfieldBounds top and: [delta y < 0]) + or: [costumeBounds bottom > playfieldBounds bottom and: [delta y > 0]]) + ifTrue: [ + delta := delta x @ delta y negated. + didStray := true]. + (didStray and: [Preferences fenceSoundEnabled]) ifTrue: [ + aCostume makeFenceSound]]]. + - ((aCostume left < aPlayfield left and: [delta x < 0]) or: - [aCostume right > aPlayfield right and: [delta x > 0]]) ifTrue: - [delta := delta x negated @ delta y. - didStray := true]. - ((aCostume top < aPlayfield top and: [delta y < 0]) or: - [aCostume bottom > aPlayfield bottom and: [delta y > 0]]) ifTrue: - [delta := delta x @ delta y negated. - didStray := true]. - (didStray and: [Preferences fenceSoundEnabled]) ifTrue: [aCostume makeFenceSound]]]. - "use and record the fractional position" p := aCostume referencePosition + delta. + aCostume referencePosition: p.! - aCostume referencePosition: p! From Das.Linux at gmx.de Mon Aug 24 18:22:39 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Mon, 24 Aug 2020 20:22:39 +0200 Subject: [squeak-dev] Git and Tonel (and Magritte) In-Reply-To: <1598292778081-0.post@n4.nabble.com> References: <1598292778081-0.post@n4.nabble.com> Message-ID: > On 24.08.2020, at 20:12, Sean P. DeNigris wrote: > > We would like to port Magritte to Tonel because we have reports of problems > on Windows with long filenames and would like to understand the > ramifications to users. > > Three questions: > 1. Do any Squeakers load Magritte from > https://github.com/magritte-metamodel/magritte ? I used to. > 2. Does Squeak support git? Yes. > 3. Does Squeak support Tonel? No. Best regards -tobias > > I found references to 2 and 3 in this ML, but nothing definitive. I'm > generally interested in those answers beyond the current porting effort. > > In short, will anyone be disrupted by the proposed migration? From christoph.thiede at student.hpi.uni-potsdam.de Mon Aug 24 18:23:47 2020 From: christoph.thiede at student.hpi.uni-potsdam.de (Christoph Thiede) Date: Mon, 24 Aug 2020 13:23:47 -0500 (CDT) Subject: [squeak-dev] Cannot reply on Nabble any longer In-Reply-To: <1598292918680-0.post@n4.nabble.com> References: <3494ce32ce334cd7b8b40c1b5ecfe439@student.hpi.uni-potsdam.de> <1598292918680-0.post@n4.nabble.com> Message-ID: <1598293427399-0.post@n4.nabble.com> If you receive this message, it works again. Great, thanks for caring! Best, Christoph -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From sean at clipperadams.com Mon Aug 24 18:36:47 2020 From: sean at clipperadams.com (Sean P. DeNigris) Date: Mon, 24 Aug 2020 13:36:47 -0500 (CDT) Subject: [squeak-dev] Cannot reply on Nabble any longer In-Reply-To: <1598293427399-0.post@n4.nabble.com> References: <3494ce32ce334cd7b8b40c1b5ecfe439@student.hpi.uni-potsdam.de> <1598292918680-0.post@n4.nabble.com> <1598293427399-0.post@n4.nabble.com> Message-ID: <1598294207758-0.post@n4.nabble.com> Christoph Thiede wrote > If you receive this message, it works again. Received. Glad it worked :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html From karlramberg at gmail.com Mon Aug 24 19:03:58 2020 From: karlramberg at gmail.com (karl ramberg) Date: Mon, 24 Aug 2020 21:03:58 +0200 Subject: [squeak-dev] The Inbox: Graphics-ct.437.mcz In-Reply-To: <3d88675e-5375-63c7-5e30-1f06c88d2896@zogotounga.net> References: <3d88675e-5375-63c7-5e30-1f06c88d2896@zogotounga.net> Message-ID: Scaling for morphs with TransformationMorph is a little weird. If you rotate a SystemWindow and use the scale handle, the window scales as a form Best, Karl On Mon, Aug 24, 2020 at 2:25 PM Stéphane Rollandin wrote: > > In my opinion, the integer/float arithmetic of Point and Rectangle is > > not really clear > Indeed. > > In my own images I have implemented #preciseCenter: and similar methods > both in Pont and Rectangle to bypass rounding and work with floats. > > But I do not think that transitioning to an overall new convention (like > getting rid of rounding altogether) is going to be safe. A lot of > morphic code assumes that rectangles are always about pixels and expect > their dimensions to be integers. > > Stef > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Mon Aug 24 20:34:38 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 24 Aug 2020 16:34:38 -0400 Subject: [squeak-dev] Cannot reply on Nabble any longer In-Reply-To: <1598294207758-0.post@n4.nabble.com> References: <3494ce32ce334cd7b8b40c1b5ecfe439@student.hpi.uni-potsdam.de> <1598292918680-0.post@n4.nabble.com> <1598293427399-0.post@n4.nabble.com> <1598294207758-0.post@n4.nabble.com> Message-ID: <20200824203438.GA35771@shell.msen.com> Thank you Sean! On Mon, Aug 24, 2020 at 01:36:47PM -0500, Sean P. DeNigris wrote: > Christoph Thiede wrote > > If you receive this message, it works again. > > Received. Glad it worked :) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Squeak-Dev-f45488.html > From LEnglish5 at cox.net Tue Aug 25 02:21:10 2020 From: LEnglish5 at cox.net (LawsonEnglish) Date: Mon, 24 Aug 2020 19:21:10 -0700 Subject: [squeak-dev] Got FFI working on my own builds (production and debug) but downloaded all-in-one always never works In-Reply-To: References: <756E4228-4A03-46EF-8D55-AA9BFD6D56A8@cox.net> Message-ID: <7CCB4B40-5AF9-4315-B15E-35741C87376C@cox.net> [hopefully this won’t cause my ISP more headaches like it did last night] I did the test of changing info.plist and adding the libraries and image/changes files to the SqueakDebug, Squeak and Squeak.assert apps and they all work just fine with my FFI. So my own compiled Squeak dylib doesn’t have the problem, while the Squeak dylib in the MacOS director in the all-in-one package does. . The big holdup now is to get mpfr_get_str() working. char * mpfr_get_str (char *str, mpfr_exp_t *expptr, int base, size_t n, mpfr_t op, mpfr_rnd_t rnd) In the simplest call, giving a NULL buffer and passing 0 via expptr returns the answer in a string buffer allocated by mpfr itself and returns the exponent via expptr. Thus far, I can’t quite get that to work. Crashes squeak every time. Some people didn’t even realize that you can pass a "hand-made” external pointer into a variable using the FFI library, so the documentation isn’t exactly clear here. I couldn’t find an example of doing this in the test library so I’m trying to figure it out on my own and so far, Its not quite working. anyway, thanks for everyone’s suggestions. L > On Aug 22, 2020, at 10:38 AM, Eliot Miranda wrote: > > Hi Lawson, > > On Thu, Aug 20, 2020 at 1:56 PM LawsonEnglish > wrote: > So, with Craig Latta’s help, I managed to build my own vm. I added back in the 5.3-19435 image and changes files, and sources file, and changed the plist appropriately and it works just fine. > > Yay! > > However, I never did get the distributed version to work. I can sorta make it work with enough swapping of files, but it eventually crashes on startup even though FFI to my own dylib is working. > > The unmodified distributed 5.3 all-in-work apparently ALWAYS eventually crashes onstartup after trying to load a dylib and then staving, if I do it enough times, but thus far the ones I built do not do this. > > If you run with an assert 5.3 VM build do you see anything indicative? And are you saying that the 5.3 distribution also crashes on a recent VM? > > I can continue with my FFI experiments now (thanks everyone for their help), but unless something is very wrong with my Mac’s setup, the latst vesion of catalina isn’t stable for FFI via dylib. > > > L > > _,,,^..^,,,_ > best, Eliot > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tom.Beckmann at student.hpi.uni-potsdam.de Tue Aug 25 06:15:55 2020 From: Tom.Beckmann at student.hpi.uni-potsdam.de (Beckmann, Tom) Date: Tue, 25 Aug 2020 06:15:55 +0000 Subject: [squeak-dev] Git and Tonel (and Magritte) In-Reply-To: References: <1598292778081-0.post@n4.nabble.com>, Message-ID: <81c1b57a154e4208a2a00c442b772d7c@student.hpi.uni-potsdam.de> Hi Sean, we added initial support for Tonel in Squeak in this somewhat recent Metacello PR: https://github.com/Metacello/metacello/pull/515 It has not undergone as much testing as the filetree infrastructure and people occasionally still find bugs. Additionally, since we do not have a tight integration with the underlying git repo, versions and author timestamps are lost when loading Tonel repos in Squeak at the moment. My personal opinion is that if you have showstopping issues on Windows due to filetree, moving to Tonel is the right call. Maybe you could consider doing the transition on a branch first, try loading it in Squeak5.3, and report any issues you notice. Best, Tom ________________________________________ From: Squeak-dev on behalf of Tobias Pape Sent: Monday, August 24, 2020 8:22:39 PM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] Git and Tonel (and Magritte) > On 24.08.2020, at 20:12, Sean P. DeNigris wrote: > > We would like to port Magritte to Tonel because we have reports of problems > on Windows with long filenames and would like to understand the > ramifications to users. > > Three questions: > 1. Do any Squeakers load Magritte from > https://github.com/magritte-metamodel/magritte ? I used to. > 2. Does Squeak support git? Yes. > 3. Does Squeak support Tonel? No. Best regards -tobias > > I found references to 2 and 3 in this ML, but nothing definitive. I'm > generally interested in those answers beyond the current porting effort. > > In short, will anyone be disrupted by the proposed migration? From Das.Linux at gmx.de Tue Aug 25 06:17:05 2020 From: Das.Linux at gmx.de (Tobias Pape) Date: Tue, 25 Aug 2020 08:17:05 +0200 Subject: [squeak-dev] Git and Tonel (and Magritte) In-Reply-To: <81c1b57a154e4208a2a00c442b772d7c@student.hpi.uni-potsdam.de> References: <1598292778081-0.post@n4.nabble.com> <81c1b57a154e4208a2a00c442b772d7c@student.hpi.uni-potsdam.de> Message-ID: Hi > On 25.08.2020, at 08:15, Beckmann, Tom wrote: > > Hi Sean, > > we added initial support for Tonel in Squeak in this somewhat recent Metacello PR: https://github.com/Metacello/metacello/pull/515 > > It has not undergone as much testing as the filetree infrastructure and people occasionally still find bugs. Additionally, since we do not have a tight integration with the underlying git repo, versions and author timestamps are lost when loading Tonel repos in Squeak at the moment. > > My personal opinion is that if you have showstopping issues on Windows due to filetree, moving to Tonel is the right call. Maybe you could consider doing the transition on a branch first, try loading it in Squeak5.3, and report any issues you notice. > It would make me sad to see it go Tonel. but that's just me :) -t > Best, > Tom > ________________________________________ > From: Squeak-dev on behalf of Tobias Pape > Sent: Monday, August 24, 2020 8:22:39 PM > To: The general-purpose Squeak developers list > Subject: Re: [squeak-dev] Git and Tonel (and Magritte) > >> On 24.08.2020, at 20:12, Sean P. DeNigris wrote: >> >> We would like to port Magritte to Tonel because we have reports of problems >> on Windows with long filenames and would like to understand the >> ramifications to users. >> >> Three questions: >> 1. Do any Squeakers load Magritte from >> https://github.com/magritte-metamodel/magritte ? > > I used to. > >> 2. Does Squeak support git? > > Yes. > >> 3. Does Squeak support Tonel? > > No. > > Best regards > -tobias > >> >> I found references to 2 and 3 in this ML, but nothing definitive. I'm >> generally interested in those answers beyond the current porting effort. >> >> In short, will anyone be disrupted by the proposed migration? > > > > From builds at travis-ci.org Tue Aug 25 14:56:48 2020 From: builds at travis-ci.org (Travis CI) Date: Tue, 25 Aug 2020 14:56:48 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1805 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f4526b03690_13fdc947a9b2020608a@travis-tasks-58ccc756b5-gjbf7.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1805 Status: Errored Duration: 18 mins and 0 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/721018958?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trygver at ifi.uio.no Tue Aug 25 15:18:50 2020 From: trygver at ifi.uio.no (Trygve Reenskaug) Date: Tue, 25 Aug 2020 17:18:50 +0200 Subject: [squeak-dev] Distributed Squeak In-Reply-To: <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> References: <9487f3df-7d50-4787-e040-6be220748f6d@ifi.uio.no> <2c5f0fa5-9f56-5d37-bdf8-964a62f698f2@ifi.uio.no> Message-ID: Is there a server somewhere where I can deploy a Squeak object and make it available on the Net through its interface? If so, is there some documentation I can read? Best --Trygve On 2020-08-15 09:56, Trygve Reenskaug wrote: > Just an idea while a car is waiting to take me on a vacation. > > Imagine: > > 1. You have a computer with many independently running images. > 2. A super fast facility pass messages between the images, > 3. Selected services in the release image are move out and deployed > as server objects in another image. > 4. Every image appears as a server offering RESTful interfaces to > other images. > 5. Selected packages in any repository can be downloaded, compiled, > instantiated, and deployed in an image as server objects. > 6. The different images can even run in different computers and use > different VMs. > 7. There are now two dimensions to the reuse of functionality: a) > download and compile a package. b In some image, install a package > and deploy it as a server object. > 8. And presto: The original image is now small and manageable while > the whole system can grow without increasing the complexity of the > release image. > > In haste. This is just an idea. It's full of holes and need a lot of > work done to it before it can be usable.. It's a disruptive idea, so > please give it some consideration This is before you shoot it down > --Trygve > > > > > > On 2020-08-14 22:54, karl ramberg wrote: >> Well said, Vanessa :-) >> >> The complexity comes from people using Squeak and wanting to improve >> it in many directions. >> And managing code , graphics , user interface , faster virtual >> machine, networking, security etc. are hard problems which add >> complexity. >> And also the added accidental complexity on top of that. >> >> It seems systems only are simple and elegant until people start using >> them. >> One can see that as a good or bad thing. >> >> Solution to the complexity problem will probably take a few >> generations to solve... >> >> Best, >> Karl >> >> >> >> On Fri, Aug 14, 2020 at 9:42 PM Vanessa Freudenberg >> > wrote: >> >> On Fri, Aug 14, 2020 at 2:31 AM Marcel Taeumel >> > wrote: >> >> Hi Trygve, >> >> I apologize for any misunderstandings here. I am not an >> English native speaker. It was not my intent do accuse you of >> lying. >> >> However, there is a difference between a bug report and an >> unsubstantiated rant. I did read your entire post "A Sad Day" >> as the latter. Whose mistake that was, I cannot tell now. >> Neutral, objective bug reports would read different, I suppose. >> >> >> It was neither a bug report nor an unsubstantiated rant. It was a >> criticism of the complexity of all current Smalltalks. The few >> examples of unexpected complexity in Squeak that Trygve chose to >> mention are not the actual issue. No need to feel personally >> attacked. >> >> Having worked with a beautifully tiny system like Smalltalk-78, >> or even early versions of Squeak, the complexity in modern Squeak >> is staggering. >> >> Smalltalk used to be a system that can be fully understood by a >> single person - truly a personal computing system. That is no >> longer the case. >> >> All the functionality we added over the years comes at the price >> of complexity (not to mention speed). It makes the system hard to >> understand. It makes it hard to see the design principles. We >> have not found a way to eliminate, or at least hide, any of the >> complexity we introduced. >> >> I don't think there is a "solution" for this within the current >> system. We have accepted the complexity, and now we have to live >> with it. And we have to accept that that alienates people who are >> looking for simplicity and elegance. >> >> I am sad to see Trygve leave, but I do understand. He didn't even >> owe us an explanation. Thank you, Trygve! >> >> All the best, >> Vanessa >> >> > > -- > > /The essence of object orientation is that objects collaborateto > achieve a goal. / > Trygve Reenskaug mailto: trygver at ifi.uio.no > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway                     Tel: (+47) 468 58 625 > -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver at ifi.uio.no Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway                     Tel: (+47) 468 58 625 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Wed Aug 26 09:20:11 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed, 26 Aug 2020 02:20:11 -0700 Subject: [squeak-dev] Git and Tonel (and Magritte) In-Reply-To: References: Message-ID: <85E55EC4-ACF4-43B6-9F46-5ECBEE75A291@gmail.com> > On Aug 24, 2020, at 11:17 PM, Tobias Pape wrote: > > Hi > >> On 25.08.2020, at 08:15, Beckmann, Tom wrote: >> >> Hi Sean, >> >> we added initial support for Tonel in Squeak in this somewhat recent Metacello PR: https://github.com/Metacello/metacello/pull/515 >> >> It has not undergone as much testing as the filetree infrastructure and people occasionally still find bugs. Additionally, since we do not have a tight integration with the underlying git repo, versions and author timestamps are lost when loading Tonel repos in Squeak at the moment. >> >> My personal opinion is that if you have showstopping issues on Windows due to filetree, moving to Tonel is the right call. Maybe you could consider doing the transition on a branch first, try loading it in Squeak5.3, and report any issues you notice. >> > > It would make me sad to see it go Tonel. > but that's just me :) If we go with Tonel then we must change it to support method timestamps. I have a change set that does this (it is a trivial change). And my changes are controlled by a class variable so that the same code can produce Pharo format or a slightly modified format that includes method timestamps. What I don’t understand is why Esteban Lorenzano refuses to accept my changes and allow Tonel to be used either with or without method timestamps. > -t > >> Best, >> Tom >> ________________________________________ >> From: Squeak-dev on behalf of Tobias Pape >> Sent: Monday, August 24, 2020 8:22:39 PM >> To: The general-purpose Squeak developers list >> Subject: Re: [squeak-dev] Git and Tonel (and Magritte) >> >>>> On 24.08.2020, at 20:12, Sean P. DeNigris wrote: >>> >>> We would like to port Magritte to Tonel because we have reports of problems >>> on Windows with long filenames and would like to understand the >>> ramifications to users. >>> >>> Three questions: >>> 1. Do any Squeakers load Magritte from >>> https://github.com/magritte-metamodel/magritte ? >> >> I used to. >> >>> 2. Does Squeak support git? >> >> Yes. >> >>> 3. Does Squeak support Tonel? >> >> No. >> >> Best regards >> -tobias >> >>> >>> I found references to 2 and 3 in this ML, but nothing definitive. I'm >>> generally interested in those answers beyond the current porting effort. >>> >>> In short, will anyone be disrupted by the proposed migration? >> >> >> >> > > > From forums.jakob at resfarm.de Wed Aug 26 09:45:03 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Wed, 26 Aug 2020 11:45:03 +0200 Subject: [squeak-dev] Git and Tonel (and Magritte) In-Reply-To: <85E55EC4-ACF4-43B6-9F46-5ECBEE75A291@gmail.com> References: <85E55EC4-ACF4-43B6-9F46-5ECBEE75A291@gmail.com> Message-ID: Hi Eliot, Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda : > > If we go with Tonel then we must change it to support method timestamps. I have a change set that does this (it is a trivial change). And my changes are controlled by a class variable so that the same code can produce Pharo format or a slightly modified format that includes method timestamps. > > What I don’t understand is why Esteban Lorenzano refuses to accept my changes and allow Tonel to be used either with or without method timestamps. > Method timestamps produce merge conflicts inevitably. Can you re-post your changeset here? https://github.com/squeak-smalltalk/squeak-tonel/issues Then we could discuss whether to include it at least in the Squeak version. As we have heard from Mariano some time ago, VA Smalltalk also puts its dialect-specific metadata in the Tonel format, so Squeak would not be the first to do so. Kind regards, Jakob From commits at source.squeak.org Wed Aug 26 13:49:10 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Wed, 26 Aug 2020 13:49:10 0000 Subject: [squeak-dev] The Trunk: Morphic-mt.1675.mcz Message-ID: Marcel Taeumel uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-mt.1675.mcz ==================== Summary ==================== Name: Morphic-mt.1675 Author: mt Time: 26 August 2020, 3:49:04.632388 pm UUID: ed707aec-b6db-fc49-9e76-56f61780e8a4 Ancestors: Morphic-mt.1674 Refactors #needsClickToFocus to #handlesKeyboardOnlyOnFocus to be useful for all kinds of morphs. For backwards compatibility, preserves the simple override "handlesKeyboard:evt \ ^true" without breaking this mechanism. So, this guard is exactly at the same place, where auto-focus is implemented: Morph >> #handleKeystroke:. Thanks to Christoph (ct)! =============== Diff against Morphic-mt.1674 =============== Item was changed: ----- Method: DialogWindow>>createMessage: (in category 'initialization') ----- createMessage: aString messageMorph := aString asText asMorph. messageMorph name: 'Message'; readOnly: true; setProperty: #indicateKeyboardFocus toValue: #never; + handlesKeyboardOnlyOnFocus: true. "If user presses enter while only hovering the text, we want to process the stroke to close the dialog." - setProperty: #needsClickToFocus toValue: true. self setMessageParameters. ^ messageMorph! Item was changed: ----- Method: Morph>>handleKeyDown: (in category 'events-processing') ----- handleKeyDown: anEvent "System level event handling." + anEvent wasHandled ifTrue: [^ self]. + (self handlesKeyboard: anEvent) ifFalse: [^ self]. + (anEvent hand keyboardFocus ~~ self + and: [self handlesKeyboardOnlyOnFocus]) + ifTrue: [^ self]. + - anEvent wasHandled ifTrue:[^self]. - (self handlesKeyboard: anEvent) ifFalse:[^self]. anEvent wasHandled: true. + ^ self keyDown: anEvent! - ^self keyDown: anEvent! Item was changed: ----- Method: Morph>>handleKeyUp: (in category 'events-processing') ----- handleKeyUp: anEvent "System level event handling." + anEvent wasHandled ifTrue: [^ self]. + (self handlesKeyboard: anEvent) ifFalse: [^ self]. + (anEvent hand keyboardFocus ~~ self + and: [self handlesKeyboardOnlyOnFocus]) + ifTrue: [^ self]. + - anEvent wasHandled ifTrue:[^self]. - (self handlesKeyboard: anEvent) ifFalse:[^self]. anEvent wasHandled: true. + ^ self keyUp: anEvent! - ^self keyUp: anEvent! Item was changed: ----- Method: Morph>>handleKeystroke: (in category 'events-processing') ----- handleKeystroke: anEvent "System level event handling. Has support for automatically grabbing the keyboard focus considering the keyboard focus delegate. See #newKeyboardFocus:" | handler | anEvent wasHandled ifTrue: [^ self]. (self handlesKeyboard: anEvent) ifFalse: [^ self]. + (anEvent hand keyboardFocus ~~ self + and: [self handlesKeyboardOnlyOnFocus]) + ifTrue: [^ self]. handler := self wantsKeyboardFocus ifFalse: [self] ifTrue: [(anEvent hand newKeyboardFocus: self) ifNil: [self]]. anEvent handler: handler. anEvent wasHandled: true. ^ handler keyStroke: anEvent! Item was added: + ----- Method: Morph>>handlesKeyboardOnlyOnFocus (in category 'event handling') ----- + handlesKeyboardOnlyOnFocus + "If set, reject every keyboard event until the receiver has received the keyboard focus in another way, i.e. a mouse click (see #mouseDown:) or programmatic focusing (see HandMorph >> #newKeyboardFocus:). This allows sending keyboard events to any owner of the receiver while the receiver is hovered by the hand. See senders. + A particular user is DialogWindow which looks for Enter and Escape presses and should not loose these events to the content morph unless it is explicitly focused. For the full discussion, see http://forum.world.st/The-Inbox-Morphic-cbc-1665-mcz-td5117905.html." + + ^ self valueOfProperty: #handlesKeyboardOnlyOnFocus ifAbsent: [false]! Item was added: + ----- Method: Morph>>handlesKeyboardOnlyOnFocus: (in category 'event handling') ----- + handlesKeyboardOnlyOnFocus: aBoolean + + ^ self setProperty: #handlesKeyboardOnlyOnFocus toValue: aBoolean! Item was changed: ----- Method: PluggableTextMorph>>mouseEnter: (in category 'event handling') ----- mouseEnter: event "Restore the selection in the text morph if there was a selection." super mouseEnter: event. selectionInterval ifNotNil: [:interval | textMorph editor selectInterval: selectionInterval; setEmphasisHere]. Preferences mouseOverForKeyboardFocus + ifTrue: [event hand newKeyboardFocus: self].! - ifTrue:[event hand newKeyboardFocus: self]! Item was changed: ----- Method: TextMorph>>handleKeystroke: (in category 'events-processing') ----- handleKeystroke: anEvent "Overwritten to support tab-among-fields preference." | pasteUp | anEvent wasHandled ifTrue:[^self]. (self handlesKeyboard: anEvent) ifFalse: [^ self]. + (anEvent hand keyboardFocus ~~ self + and: [self handlesKeyboardOnlyOnFocus]) + ifTrue: [^ self]. anEvent keyCharacter = Character tab ifTrue: [ "Allow passing through text morph inside pasteups" (self wouldAcceptKeyboardFocusUponTab and: [(pasteUp := self pasteUpMorphHandlingTabAmongFields) notNil]) ifTrue: [ anEvent wasHandled: true. ^ pasteUp tabHitWithEvent: anEvent]]. ^ super handleKeystroke: anEvent! Item was changed: ----- Method: TextMorph>>handlesKeyboard: (in category 'event handling') ----- + handlesKeyboard: evt + ^true! - handlesKeyboard: anEvent - - ^ ((self valueOfProperty: #needsClickToFocus ifAbsent: [false]) ==> [ - anEvent hand keyboardFocus = self])! From eliot.miranda at gmail.com Wed Aug 26 14:15:14 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed, 26 Aug 2020 07:15:14 -0700 Subject: [squeak-dev] Git and Tonel (and Magritte) In-Reply-To: References: Message-ID: <344D71FD-943D-4761-AEE0-A37EC3274174@gmail.com> Jakob, > On Aug 26, 2020, at 2:45 AM, Jakob Reschke wrote: > > Hi Eliot, > >> Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda >> : >> >> If we go with Tonel then we must change it to support method timestamps. I have a change set that does this (it is a trivial change). And my changes are controlled by a class variable so that the same code can produce Pharo format or a slightly modified format that includes method timestamps. >> >> What I don’t understand is why Esteban Lorenzano refuses to accept my changes and allow Tonel to be used either with or without method timestamps. >> > > Method timestamps produce merge conflicts inevitably. a) only when they change, and they change only when methods change b) inadvertent method timestamp changes can be undone automatically c) Squeak uses method timestamps; we have lots of tools that use them. Dropping them just so that we can use Tonel is an example of the tail wagging the dog. The Tonel interface must instead be made to function with method timestamps If there is a decision not to support method timestamps then I will not support the work. This is a make or break issue for me. > Can you re-post > your changeset here? I’ll post it later today (reading email in bed right now). > https://github.com/squeak-smalltalk/squeak-tonel/issues OK > Then we could > discuss whether to include it at least in the Squeak version. As we > have heard from Mariano some time ago, VA Smalltalk also puts its > dialect-specific metadata in the Tonel format, so Squeak would not be > the first to do so. Good. > Kind regards, > Jakob From tonyg at leastfixedpoint.com Wed Aug 26 14:20:01 2020 From: tonyg at leastfixedpoint.com (Tony Garnock-Jones) Date: Wed, 26 Aug 2020 16:20:01 +0200 Subject: [squeak-dev] TTCFont >> flushCachedValues Message-ID: <93602a53-09f8-b358-4436-b51b90d7d650@leastfixedpoint.com> Hi all, I'm looking at the image-side DPI-change code, namely TextStyle >> pixelsPerInch:. The broadcast of the change is fine. But the handler in TTCFont is subtly wrong, I think. - I believe instance variables height, ascent, descent have to be nil'd as part of pixelsPerInchChanged. Is that right? Without nil'ing them, my TTCFonts don't resize properly. - This suggests flushCachedValues, which has NO SENDERS (!), should be folded into flushCache. Does that sound right? - Finally, if both the above hold, then pixelsPerInchChanged should be calling flushCache instead of recreateCache. Does that sound right? I'll be running for a few days with these changes in my image, to see if there are any obvious problems with them. But, before I push a commit out to Trunk, if I could get a thumbs-up from someone who knows a bit about the font subsystem, that'd be great! Regards, Tony From builds at travis-ci.org Wed Aug 26 14:57:15 2020 From: builds at travis-ci.org (Travis CI) Date: Wed, 26 Aug 2020 14:57:15 +0000 Subject: [squeak-dev] [CRON] Passed: squeak-smalltalk/squeak-app#1806 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f46784d13bc2_13fc919add438241997@travis-tasks-7b7c7f8df-snmc6.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1806 Status: Passed Duration: 18 mins and 19 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/721363415?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale.henrichs at gemtalksystems.com Wed Aug 26 16:41:38 2020 From: dale.henrichs at gemtalksystems.com (Dale Henrichs) Date: Wed, 26 Aug 2020 09:41:38 -0700 Subject: [squeak-dev] Git and Tonel (and Magritte) In-Reply-To: <344D71FD-943D-4761-AEE0-A37EC3274174@gmail.com> References: <344D71FD-943D-4761-AEE0-A37EC3274174@gmail.com> Message-ID: Eliot, When you repost, could you make sure that you include a description of where the time stamps are stashed ... I'm assuming that you are adding it to the method properties (where the category is stashed) as I think that this is the right place, but it's always best not to guess:) The current crop of Tonel readers/writers do not necessarily do a good job of preserving, foreign data (IIRC, the convention is to add a platform prefix to the property name, which is the same convention used for class properties ... at GemStone we add a leading `gs_` to our property names), so until we can get all of the different Tonel readers/writers to preserve foreign properties (package, class and method) it will continue to be dicey business for preserving foreign properties in cross platform projects ... Monticello does not explicitly preserve foreign properties as the definitions get created from the native objects, so it takes some additional work to arrange to preserve foreign properties for packages, classes, and methods in the objects themselves. So it is worth considering what you will do with preserving foreign properties from other platforms. FWIW, I intend to support the preservation of foreign properties in Rowan (read that as "I haven't done that yet":) Finally, Martin McClure has started working on a spec for the next generation Tonel format ... to add a few missing pieces and tweak the format to make it possible to continue to evolve the Tonel format into the future in a somewhat sane way. If there are folks here in the Squeak community who would like to review, comment and participate in the creation of the next generation format, send me (or Martin) mail and we'll get you added to the mailing list. Dale On 8/26/20 7:15 AM, Eliot Miranda wrote: > Jakob, > >> On Aug 26, 2020, at 2:45 AM, Jakob Reschke wrote: >> >> Hi Eliot, >> >>> Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda >>> : >>> >>> If we go with Tonel then we must change it to support method timestamps. I have a change set that does this (it is a trivial change). And my changes are controlled by a class variable so that the same code can produce Pharo format or a slightly modified format that includes method timestamps. >>> >>> What I don’t understand is why Esteban Lorenzano refuses to accept my changes and allow Tonel to be used either with or without method timestamps. >>> >> Method timestamps produce merge conflicts inevitably. > a) only when they change, and they change only when methods change > b) inadvertent method timestamp changes can be undone automatically > c) Squeak uses method timestamps; we have lots of tools that use them. Dropping them just so that we can use Tonel is an example of the tail wagging the dog. The Tonel interface must instead be made to function with method timestamps > > If there is a decision not to support method timestamps then I will not support the work. This is a make or break issue for me. > >> Can you re-post >> your changeset here? > I’ll post it later today (reading email in bed right now). > >> https://github.com/squeak-smalltalk/squeak-tonel/issues > OK > >> Then we could >> discuss whether to include it at least in the Squeak version. As we >> have heard from Mariano some time ago, VA Smalltalk also puts its >> dialect-specific metadata in the Tonel format, so Squeak would not be >> the first to do so. > Good. > >> Kind regards, >> Jakob From martin at hand2mouse.com Wed Aug 26 19:20:02 2020 From: martin at hand2mouse.com (Martin McClure) Date: Wed, 26 Aug 2020 12:20:02 -0700 Subject: [squeak-dev] Squeak, Tonel, and the Tonel standard In-Reply-To: References: <344D71FD-943D-4761-AEE0-A37EC3274174@gmail.com> Message-ID: <929db24b-03d4-2939-5057-e150370da05a@hand2mouse.com> Hi all, Dale let me know this morning that Tonel was being discussed on Squeak-dev.  I beg your pardon for arriving late. As Dale said, I'm the minder of the Tonel 1.0 standard, which is currently in draft, with initial feedback from some of the folks who have implemented or are interested in implementing Tonel for their Smalltalk dialect. I'm interested in getting feedback from *all* dialects who are interested in using Tonel. I hope that the Squeak community will participate. Tonel started as a collaboration between Pharo (primarily Esteban Lorenzano) and GemTalk (primarily me), but the intent has always been to have a format that can be used in common between *all* dialects of Smalltalk. The fundamental shape of Tonel is probably not going to change at this point, but feedback so far is likely to result in some changes to the draft standard. Note that Tonel as currently implemented by Pharo is a bit different from standard Tonel. Pharo has agreed to make several changes to the format to standardize it. I'm not sure what the status of those changes within the Pharo project. The GemStone implementation is closer to the standard, though not fully there yet. I encourage the Squeak community to consider whether coding to the standard early on might be a desirable direction. As Dale explained, the standard does allow for dialect-specific properties, so adding timestamps probably doesn't require any changes to the spec. I'd like it If a few folks from the community would volunteer to give the spec a careful read-through and comment. It's a bit of a read (and was quite a bit of effort to write!) so I won't post the draft on the list, but it's available by request, and I need to figure out a place to make it readily available. Regards, -Martin On 8/26/20 9:41 AM, Dale Henrichs wrote: > Eliot, > > When you repost, could you make sure that you include a description of > where the time stamps are stashed ... I'm assuming that you are adding > it to the method properties (where the category is stashed) as I think > that this is the right place, but it's always best not to guess:) > > The current crop of Tonel readers/writers do not necessarily do a good > job of preserving, foreign data (IIRC, the convention is to add a > platform prefix to the property name, which is the same convention > used for class properties ... at GemStone we add a leading `gs_` to > our property names), so until we can get all of the different Tonel > readers/writers to preserve foreign properties (package, class and > method) it will continue to be dicey business for preserving foreign > properties in cross platform projects ... > > Monticello does not explicitly preserve foreign properties as the > definitions get created from the native objects, so it takes some > additional work to arrange to preserve foreign properties for > packages, classes, and methods in the objects themselves. So it is > worth considering what you will do with preserving foreign properties > from other platforms. > > FWIW, I intend to support the preservation of foreign properties in > Rowan (read that as "I haven't done that yet":) > > Finally, Martin McClure has started working on a spec for the next > generation Tonel format ... to add a few missing pieces and tweak the > format to make it possible to continue to evolve the Tonel format into > the future in a somewhat sane way. If there are folks here in the > Squeak community who would like to review, comment and participate in > the creation of the next generation format, send me (or Martin) mail > and we'll get you added to the mailing list. > > Dale > > On 8/26/20 7:15 AM, Eliot Miranda wrote: >> Jakob, >> >>> On Aug 26, 2020, at 2:45 AM, Jakob Reschke >>> wrote: >>> >>> Hi Eliot, >>> >>>> Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda >>>> : >>>> >>>> If we go with Tonel then we must change it to support method >>>> timestamps.  I have a change set that does this (it is a trivial >>>> change).  And my changes are controlled by a class variable so that >>>> the same code can produce Pharo format or a slightly modified >>>> format that includes method timestamps. >>>> >>>> What I don’t understand is why Esteban Lorenzano refuses to accept >>>> my changes and allow Tonel to be used either with or without method >>>> timestamps. >>>> >>> Method timestamps produce merge conflicts inevitably. >> a) only when they change, and they change only when methods change >> b) inadvertent method timestamp changes can be undone automatically >> c) Squeak uses method timestamps; we have lots of tools that use >> them. Dropping them just so that we can use Tonel is an example of >> the tail wagging the dog. The Tonel interface must instead be made to >> function with method timestamps >> >> If there is a decision not to support method timestamps then I will >> not support the work. This is a make or break issue for me. >> >>> Can you re-post >>> your changeset here? >> I’ll post it later today (reading email in bed right now). >> >>> https://github.com/squeak-smalltalk/squeak-tonel/issues >> OK >> >>> Then we could >>> discuss whether to include it at least in the Squeak version. As we >>> have heard from Mariano some time ago, VA Smalltalk also puts its >>> dialect-specific metadata in the Tonel format, so Squeak would not be >>> the first to do so. >> Good. >> >>> Kind regards, >>> Jakob > From forums.jakob at resfarm.de Wed Aug 26 20:04:49 2020 From: forums.jakob at resfarm.de (Jakob Reschke) Date: Wed, 26 Aug 2020 22:04:49 +0200 Subject: [squeak-dev] Squeak, Tonel, and the Tonel standard In-Reply-To: <929db24b-03d4-2939-5057-e150370da05a@hand2mouse.com> References: <344D71FD-943D-4761-AEE0-A37EC3274174@gmail.com> <929db24b-03d4-2939-5057-e150370da05a@hand2mouse.com> Message-ID: Hello Martin, While I probably won't be able to provide comprehensive feedback or even read the whole text in the near future, I would certainly be interested to have a look. What is the licensing status of the draft and future proposed standard? If it is in some plain text/markup format, is it possible to upload the draft to a public GitHub repository? Or something similar that allows for commenting on changes. On GitHub one can only comment on diffs, but the initial commit will add all the lines, so one could still comment on all of the text. Also people could provide suggested changes via pull requests. Kind regards, Jakob Am Mi., 26. Aug. 2020 um 21:20 Uhr schrieb Martin McClure : > > Hi all, > > Dale let me know this morning that Tonel was being discussed on > Squeak-dev. I beg your pardon for arriving late. > > As Dale said, I'm the minder of the Tonel 1.0 standard, which is > currently in draft, with initial feedback from some of the folks who > have implemented or are interested in implementing Tonel for their > Smalltalk dialect. > > I'm interested in getting feedback from *all* dialects who are > interested in using Tonel. I hope that the Squeak community will > participate. > > Tonel started as a collaboration between Pharo (primarily Esteban > Lorenzano) and GemTalk (primarily me), but the intent has always been to > have a format that can be used in common between *all* dialects of > Smalltalk. The fundamental shape of Tonel is probably not going to > change at this point, but feedback so far is likely to result in some > changes to the draft standard. > > Note that Tonel as currently implemented by Pharo is a bit different > from standard Tonel. Pharo has agreed to make several changes to the > format to standardize it. I'm not sure what the status of those changes > within the Pharo project. The GemStone implementation is closer to the > standard, though not fully there yet. > > I encourage the Squeak community to consider whether coding to the > standard early on might be a desirable direction. As Dale explained, the > standard does allow for dialect-specific properties, so adding > timestamps probably doesn't require any changes to the spec. > > I'd like it If a few folks from the community would volunteer to give > the spec a careful read-through and comment. It's a bit of a read (and > was quite a bit of effort to write!) so I won't post the draft on the > list, but it's available by request, and I need to figure out a place to > make it readily available. > > Regards, > -Martin > > > On 8/26/20 9:41 AM, Dale Henrichs wrote: > > Eliot, > > > > When you repost, could you make sure that you include a description of > > where the time stamps are stashed ... I'm assuming that you are adding > > it to the method properties (where the category is stashed) as I think > > that this is the right place, but it's always best not to guess:) > > > > The current crop of Tonel readers/writers do not necessarily do a good > > job of preserving, foreign data (IIRC, the convention is to add a > > platform prefix to the property name, which is the same convention > > used for class properties ... at GemStone we add a leading `gs_` to > > our property names), so until we can get all of the different Tonel > > readers/writers to preserve foreign properties (package, class and > > method) it will continue to be dicey business for preserving foreign > > properties in cross platform projects ... > > > > Monticello does not explicitly preserve foreign properties as the > > definitions get created from the native objects, so it takes some > > additional work to arrange to preserve foreign properties for > > packages, classes, and methods in the objects themselves. So it is > > worth considering what you will do with preserving foreign properties > > from other platforms. > > > > FWIW, I intend to support the preservation of foreign properties in > > Rowan (read that as "I haven't done that yet":) > > > > Finally, Martin McClure has started working on a spec for the next > > generation Tonel format ... to add a few missing pieces and tweak the > > format to make it possible to continue to evolve the Tonel format into > > the future in a somewhat sane way. If there are folks here in the > > Squeak community who would like to review, comment and participate in > > the creation of the next generation format, send me (or Martin) mail > > and we'll get you added to the mailing list. > > > > Dale > > > > On 8/26/20 7:15 AM, Eliot Miranda wrote: > >> Jakob, > >> > >>> On Aug 26, 2020, at 2:45 AM, Jakob Reschke > >>> wrote: > >>> > >>> Hi Eliot, > >>> > >>>> Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda > >>>> : > >>>> > >>>> If we go with Tonel then we must change it to support method > >>>> timestamps. I have a change set that does this (it is a trivial > >>>> change). And my changes are controlled by a class variable so that > >>>> the same code can produce Pharo format or a slightly modified > >>>> format that includes method timestamps. > >>>> > >>>> What I don’t understand is why Esteban Lorenzano refuses to accept > >>>> my changes and allow Tonel to be used either with or without method > >>>> timestamps. > >>>> > >>> Method timestamps produce merge conflicts inevitably. > >> a) only when they change, and they change only when methods change > >> b) inadvertent method timestamp changes can be undone automatically > >> c) Squeak uses method timestamps; we have lots of tools that use > >> them. Dropping them just so that we can use Tonel is an example of > >> the tail wagging the dog. The Tonel interface must instead be made to > >> function with method timestamps > >> > >> If there is a decision not to support method timestamps then I will > >> not support the work. This is a make or break issue for me. > >> > >>> Can you re-post > >>> your changeset here? > >> I’ll post it later today (reading email in bed right now). > >> > >>> https://github.com/squeak-smalltalk/squeak-tonel/issues > >> OK > >> > >>> Then we could > >>> discuss whether to include it at least in the Squeak version. As we > >>> have heard from Mariano some time ago, VA Smalltalk also puts its > >>> dialect-specific metadata in the Tonel format, so Squeak would not be > >>> the first to do so. > >> Good. > >> > >>> Kind regards, > >>> Jakob > > > > From martin at hand2mouse.com Wed Aug 26 20:37:17 2020 From: martin at hand2mouse.com (Martin McClure) Date: Wed, 26 Aug 2020 13:37:17 -0700 Subject: [squeak-dev] Squeak, Tonel, and the Tonel standard In-Reply-To: References: <344D71FD-943D-4761-AEE0-A37EC3274174@gmail.com> <929db24b-03d4-2939-5057-e150370da05a@hand2mouse.com> Message-ID: Hi Jakob, Thanks for your interest. I'll send you the draft under separate cover. Putting it on GitHub is probably the best option -- I'll try to get that set up within the next couple of days, and announce it on the list when I do. Regards, -Martin On 8/26/20 1:04 PM, Jakob Reschke wrote: > Hello Martin, > > While I probably won't be able to provide comprehensive feedback or > even read the whole text in the near future, I would certainly be > interested to have a look. > > What is the licensing status of the draft and future proposed > standard? If it is in some plain text/markup format, is it possible to > upload the draft to a public GitHub repository? Or something similar > that allows for commenting on changes. On GitHub one can only comment > on diffs, but the initial commit will add all the lines, so one could > still comment on all of the text. Also people could provide suggested > changes via pull requests. > > Kind regards, > Jakob > > Am Mi., 26. Aug. 2020 um 21:20 Uhr schrieb Martin McClure > : >> Hi all, >> >> Dale let me know this morning that Tonel was being discussed on >> Squeak-dev. I beg your pardon for arriving late. >> >> As Dale said, I'm the minder of the Tonel 1.0 standard, which is >> currently in draft, with initial feedback from some of the folks who >> have implemented or are interested in implementing Tonel for their >> Smalltalk dialect. >> >> I'm interested in getting feedback from *all* dialects who are >> interested in using Tonel. I hope that the Squeak community will >> participate. >> >> Tonel started as a collaboration between Pharo (primarily Esteban >> Lorenzano) and GemTalk (primarily me), but the intent has always been to >> have a format that can be used in common between *all* dialects of >> Smalltalk. The fundamental shape of Tonel is probably not going to >> change at this point, but feedback so far is likely to result in some >> changes to the draft standard. >> >> Note that Tonel as currently implemented by Pharo is a bit different >> from standard Tonel. Pharo has agreed to make several changes to the >> format to standardize it. I'm not sure what the status of those changes >> within the Pharo project. The GemStone implementation is closer to the >> standard, though not fully there yet. >> >> I encourage the Squeak community to consider whether coding to the >> standard early on might be a desirable direction. As Dale explained, the >> standard does allow for dialect-specific properties, so adding >> timestamps probably doesn't require any changes to the spec. >> >> I'd like it If a few folks from the community would volunteer to give >> the spec a careful read-through and comment. It's a bit of a read (and >> was quite a bit of effort to write!) so I won't post the draft on the >> list, but it's available by request, and I need to figure out a place to >> make it readily available. >> >> Regards, >> -Martin >> >> >> On 8/26/20 9:41 AM, Dale Henrichs wrote: >>> Eliot, >>> >>> When you repost, could you make sure that you include a description of >>> where the time stamps are stashed ... I'm assuming that you are adding >>> it to the method properties (where the category is stashed) as I think >>> that this is the right place, but it's always best not to guess:) >>> >>> The current crop of Tonel readers/writers do not necessarily do a good >>> job of preserving, foreign data (IIRC, the convention is to add a >>> platform prefix to the property name, which is the same convention >>> used for class properties ... at GemStone we add a leading `gs_` to >>> our property names), so until we can get all of the different Tonel >>> readers/writers to preserve foreign properties (package, class and >>> method) it will continue to be dicey business for preserving foreign >>> properties in cross platform projects ... >>> >>> Monticello does not explicitly preserve foreign properties as the >>> definitions get created from the native objects, so it takes some >>> additional work to arrange to preserve foreign properties for >>> packages, classes, and methods in the objects themselves. So it is >>> worth considering what you will do with preserving foreign properties >>> from other platforms. >>> >>> FWIW, I intend to support the preservation of foreign properties in >>> Rowan (read that as "I haven't done that yet":) >>> >>> Finally, Martin McClure has started working on a spec for the next >>> generation Tonel format ... to add a few missing pieces and tweak the >>> format to make it possible to continue to evolve the Tonel format into >>> the future in a somewhat sane way. If there are folks here in the >>> Squeak community who would like to review, comment and participate in >>> the creation of the next generation format, send me (or Martin) mail >>> and we'll get you added to the mailing list. >>> >>> Dale >>> >>> On 8/26/20 7:15 AM, Eliot Miranda wrote: >>>> Jakob, >>>> >>>>> On Aug 26, 2020, at 2:45 AM, Jakob Reschke >>>>> wrote: >>>>> >>>>> Hi Eliot, >>>>> >>>>>> Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda >>>>>> : >>>>>> >>>>>> If we go with Tonel then we must change it to support method >>>>>> timestamps. I have a change set that does this (it is a trivial >>>>>> change). And my changes are controlled by a class variable so that >>>>>> the same code can produce Pharo format or a slightly modified >>>>>> format that includes method timestamps. >>>>>> >>>>>> What I don’t understand is why Esteban Lorenzano refuses to accept >>>>>> my changes and allow Tonel to be used either with or without method >>>>>> timestamps. >>>>>> >>>>> Method timestamps produce merge conflicts inevitably. >>>> a) only when they change, and they change only when methods change >>>> b) inadvertent method timestamp changes can be undone automatically >>>> c) Squeak uses method timestamps; we have lots of tools that use >>>> them. Dropping them just so that we can use Tonel is an example of >>>> the tail wagging the dog. The Tonel interface must instead be made to >>>> function with method timestamps >>>> >>>> If there is a decision not to support method timestamps then I will >>>> not support the work. This is a make or break issue for me. >>>> >>>>> Can you re-post >>>>> your changeset here? >>>> I’ll post it later today (reading email in bed right now). >>>> >>>>> https://github.com/squeak-smalltalk/squeak-tonel/issues >>>> OK >>>> >>>>> Then we could >>>>> discuss whether to include it at least in the Squeak version. As we >>>>> have heard from Mariano some time ago, VA Smalltalk also puts its >>>>> dialect-specific metadata in the Tonel format, so Squeak would not be >>>>> the first to do so. >>>> Good. >>>> >>>>> Kind regards, >>>>> Jakob >> From squeaklist at gmail.com Thu Aug 27 00:04:31 2020 From: squeaklist at gmail.com (Kjell Godo) Date: Wed, 26 Aug 2020 17:04:31 -0700 Subject: [squeak-dev] Squeak, Tonel, and the Tonel standard In-Reply-To: References: <344D71FD-943D-4761-AEE0-A37EC3274174@gmail.com> <929db24b-03d4-2939-5057-e150370da05a@hand2mouse.com> Message-ID: i realize that you want to keep the ball rolling and all and not waste the previous efforts but why make a special Tonel syntax ? why not just use Smalltalk and String literals Number literals etc then it will be easy to change and isn’t this whole chunk format that shows up in Package Files an artifact of the limited hardware of yor or i can’t tell why they used it instead of just using Smalltalk i can’t see why you wouldn’t just use Smalltalk instead of these ! ! bang things and all are there some C style hard limits that can run you afoul ? no there are not but this is not helping to keep the ball rolling no On Wed, Aug 26, 2020 at 13:37 Martin McClure wrote: > Hi Jakob, > > Thanks for your interest. I'll send you the draft under separate cover. > Putting it on GitHub is probably the best option -- I'll try to get that > set up within the next couple of days, and announce it on the list when > I do. > > Regards, > -Martin > > On 8/26/20 1:04 PM, Jakob Reschke wrote: > > Hello Martin, > > > > While I probably won't be able to provide comprehensive feedback or > > even read the whole text in the near future, I would certainly be > > interested to have a look. > > > > What is the licensing status of the draft and future proposed > > standard? If it is in some plain text/markup format, is it possible to > > upload the draft to a public GitHub repository? Or something similar > > that allows for commenting on changes. On GitHub one can only comment > > on diffs, but the initial commit will add all the lines, so one could > > still comment on all of the text. Also people could provide suggested > > changes via pull requests. > > > > Kind regards, > > Jakob > > > > Am Mi., 26. Aug. 2020 um 21:20 Uhr schrieb Martin McClure > > : > >> Hi all, > >> > >> Dale let me know this morning that Tonel was being discussed on > >> Squeak-dev. I beg your pardon for arriving late. > >> > >> As Dale said, I'm the minder of the Tonel 1.0 standard, which is > >> currently in draft, with initial feedback from some of the folks who > >> have implemented or are interested in implementing Tonel for their > >> Smalltalk dialect. > >> > >> I'm interested in getting feedback from *all* dialects who are > >> interested in using Tonel. I hope that the Squeak community will > >> participate. > >> > >> Tonel started as a collaboration between Pharo (primarily Esteban > >> Lorenzano) and GemTalk (primarily me), but the intent has always been to > >> have a format that can be used in common between *all* dialects of > >> Smalltalk. The fundamental shape of Tonel is probably not going to > >> change at this point, but feedback so far is likely to result in some > >> changes to the draft standard. > >> > >> Note that Tonel as currently implemented by Pharo is a bit different > >> from standard Tonel. Pharo has agreed to make several changes to the > >> format to standardize it. I'm not sure what the status of those changes > >> within the Pharo project. The GemStone implementation is closer to the > >> standard, though not fully there yet. > >> > >> I encourage the Squeak community to consider whether coding to the > >> standard early on might be a desirable direction. As Dale explained, the > >> standard does allow for dialect-specific properties, so adding > >> timestamps probably doesn't require any changes to the spec. > >> > >> I'd like it If a few folks from the community would volunteer to give > >> the spec a careful read-through and comment. It's a bit of a read (and > >> was quite a bit of effort to write!) so I won't post the draft on the > >> list, but it's available by request, and I need to figure out a place to > >> make it readily available. > >> > >> Regards, > >> -Martin > >> > >> > >> On 8/26/20 9:41 AM, Dale Henrichs wrote: > >>> Eliot, > >>> > >>> When you repost, could you make sure that you include a description of > >>> where the time stamps are stashed ... I'm assuming that you are adding > >>> it to the method properties (where the category is stashed) as I think > >>> that this is the right place, but it's always best not to guess:) > >>> > >>> The current crop of Tonel readers/writers do not necessarily do a good > >>> job of preserving, foreign data (IIRC, the convention is to add a > >>> platform prefix to the property name, which is the same convention > >>> used for class properties ... at GemStone we add a leading `gs_` to > >>> our property names), so until we can get all of the different Tonel > >>> readers/writers to preserve foreign properties (package, class and > >>> method) it will continue to be dicey business for preserving foreign > >>> properties in cross platform projects ... > >>> > >>> Monticello does not explicitly preserve foreign properties as the > >>> definitions get created from the native objects, so it takes some > >>> additional work to arrange to preserve foreign properties for > >>> packages, classes, and methods in the objects themselves. So it is > >>> worth considering what you will do with preserving foreign properties > >>> from other platforms. > >>> > >>> FWIW, I intend to support the preservation of foreign properties in > >>> Rowan (read that as "I haven't done that yet":) > >>> > >>> Finally, Martin McClure has started working on a spec for the next > >>> generation Tonel format ... to add a few missing pieces and tweak the > >>> format to make it possible to continue to evolve the Tonel format into > >>> the future in a somewhat sane way. If there are folks here in the > >>> Squeak community who would like to review, comment and participate in > >>> the creation of the next generation format, send me (or Martin) mail > >>> and we'll get you added to the mailing list. > >>> > >>> Dale > >>> > >>> On 8/26/20 7:15 AM, Eliot Miranda wrote: > >>>> Jakob, > >>>> > >>>>> On Aug 26, 2020, at 2:45 AM, Jakob Reschke > >>>>> wrote: > >>>>> > >>>>> Hi Eliot, > >>>>> > >>>>>> Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda > >>>>>> : > >>>>>> > >>>>>> If we go with Tonel then we must change it to support method > >>>>>> timestamps. I have a change set that does this (it is a trivial > >>>>>> change). And my changes are controlled by a class variable so that > >>>>>> the same code can produce Pharo format or a slightly modified > >>>>>> format that includes method timestamps. > >>>>>> > >>>>>> What I don’t understand is why Esteban Lorenzano refuses to accept > >>>>>> my changes and allow Tonel to be used either with or without method > >>>>>> timestamps. > >>>>>> > >>>>> Method timestamps produce merge conflicts inevitably. > >>>> a) only when they change, and they change only when methods change > >>>> b) inadvertent method timestamp changes can be undone automatically > >>>> c) Squeak uses method timestamps; we have lots of tools that use > >>>> them. Dropping them just so that we can use Tonel is an example of > >>>> the tail wagging the dog. The Tonel interface must instead be made to > >>>> function with method timestamps > >>>> > >>>> If there is a decision not to support method timestamps then I will > >>>> not support the work. This is a make or break issue for me. > >>>> > >>>>> Can you re-post > >>>>> your changeset here? > >>>> I’ll post it later today (reading email in bed right now). > >>>> > >>>>> https://github.com/squeak-smalltalk/squeak-tonel/issues > >>>> OK > >>>> > >>>>> Then we could > >>>>> discuss whether to include it at least in the Squeak version. As we > >>>>> have heard from Mariano some time ago, VA Smalltalk also puts its > >>>>> dialect-specific metadata in the Tonel format, so Squeak would not be > >>>>> the first to do so. > >>>> Good. > >>>> > >>>>> Kind regards, > >>>>> Jakob > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliot.miranda at gmail.com Thu Aug 27 00:53:19 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Wed, 26 Aug 2020 17:53:19 -0700 Subject: [squeak-dev] Git and Tonel (and Magritte) In-Reply-To: References: <344D71FD-943D-4761-AEE0-A37EC3274174@gmail.com> Message-ID: Hi Dale, Hi Martin, Hi All, find attached changes that allow Tonel to *optionally* support method timestamps. This code formats the category metadata included in a Tonel source file on the same line as a method timestamp, making for something less verbose and IMO more attractive. An example of the format is this: { #category : #resources, #timeStamp : 'ThierryGoubier 3\/2\/2018 19:24:09' } MCGitTonelTests class >> gitCreateAndInitRepo: dir [ #(#('init') #('config' 'user.email' 'you at example.com') #('config' ' user.name' 'Your Name')) do: [ :c | MCTonelGitRepository runGitCommand: c in: dir ] ] I tried to get Esteban to accept these changes *as an option controlled by a preference*, so that Pharo would not have to change its format at all. But when I tried to discuss it with him in mid 2018 and again in early 2019 I was simply rebuffed. Esteban kept on mentioning merge conflicts when - if Pharo has the preference disabled it will not produce the metadata and hence will not suffer merge conflicts - a merge conflict would only be experienced had a method actually changed twice independently Since method timestamps (when correctly implemented) only change when a method actually changes (and a smart system can undo inadvertent changes) Esteban's objection is a straw man. Squeak introduced method timestamps and some of us like them (me very much) as a very convenient way to stamp methods. Any source standard hoping to be widely adopted must be flexible enough to encompass important use cases of the various dialects. On Wed, Aug 26, 2020 at 9:41 AM Dale Henrichs < dale.henrichs at gemtalksystems.com> wrote: > Eliot, > > When you repost, could you make sure that you include a description of > where the time stamps are stashed ... I'm assuming that you are adding > it to the method properties (where the category is stashed) as I think > that this is the right place, but it's always best not to guess:) > > The current crop of Tonel readers/writers do not necessarily do a good > job of preserving, foreign data (IIRC, the convention is to add a > platform prefix to the property name, which is the same convention used > for class properties ... at GemStone we add a leading `gs_` to our > property names), so until we can get all of the different Tonel > readers/writers to preserve foreign properties (package, class and > method) it will continue to be dicey business for preserving foreign > properties in cross platform projects ... > > Monticello does not explicitly preserve foreign properties as the > definitions get created from the native objects, so it takes some > additional work to arrange to preserve foreign properties for packages, > classes, and methods in the objects themselves. So it is worth > considering what you will do with preserving foreign properties from > other platforms. > > FWIW, I intend to support the preservation of foreign properties in > Rowan (read that as "I haven't done that yet":) > > Finally, Martin McClure has started working on a spec for the next > generation Tonel format ... to add a few missing pieces and tweak the > format to make it possible to continue to evolve the Tonel format into > the future in a somewhat sane way. If there are folks here in the Squeak > community who would like to review, comment and participate in the > creation of the next generation format, send me (or Martin) mail and > we'll get you added to the mailing list. > > Dale > > On 8/26/20 7:15 AM, Eliot Miranda wrote: > > Jakob, > > > >> On Aug 26, 2020, at 2:45 AM, Jakob Reschke > wrote: > >> > >> Hi Eliot, > >> > >>> Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda > >>> : > >>> > >>> If we go with Tonel then we must change it to support method > timestamps. I have a change set that does this (it is a trivial change). > And my changes are controlled by a class variable so that the same code can > produce Pharo format or a slightly modified format that includes method > timestamps. > >>> > >>> What I don’t understand is why Esteban Lorenzano refuses to accept my > changes and allow Tonel to be used either with or without method timestamps. > >>> > >> Method timestamps produce merge conflicts inevitably. > > a) only when they change, and they change only when methods change > > b) inadvertent method timestamp changes can be undone automatically > > c) Squeak uses method timestamps; we have lots of tools that use them. > Dropping them just so that we can use Tonel is an example of the tail > wagging the dog. The Tonel interface must instead be made to function with > method timestamps > > > > If there is a decision not to support method timestamps then I will not > support the work. This is a make or break issue for me. > > > >> Can you re-post > >> your changeset here? > > I’ll post it later today (reading email in bed right now). > > > >> https://github.com/squeak-smalltalk/squeak-tonel/issues > > OK > > > >> Then we could > >> discuss whether to include it at least in the Squeak version. As we > >> have heard from Mariano some time ago, VA Smalltalk also puts its > >> dialect-specific metadata in the Tonel format, so Squeak would not be > >> the first to do so. > > Good. > > > >> Kind regards, > >> Jakob > > -- _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TonelMethodTimestamps.st Type: application/octet-stream Size: 4035 bytes Desc: not available URL: From lewis at mail.msen.com Thu Aug 27 01:26:38 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Wed, 26 Aug 2020 21:26:38 -0400 Subject: [squeak-dev] Squeak, Tonel, and the Tonel standard In-Reply-To: <929db24b-03d4-2939-5057-e150370da05a@hand2mouse.com> References: <344D71FD-943D-4761-AEE0-A37EC3274174@gmail.com> <929db24b-03d4-2939-5057-e150370da05a@hand2mouse.com> Message-ID: <20200827012638.GA46766@shell.msen.com> Hi Martin, Thanks for writing this. If there was such a thing as a standard Tonel format that works correctly with Squeak, Cuis, GemStone, and Pharo, then it sounds like a very worthwhile thing. My only real interaction with Tonel involves publishing a couple of packages that I develop in Squeak for the benefit of some Pharo users. That was fine as far as it went, but beyond doing occasional exports to that format, the Pharo implementation is basically useless for me due to its inability to track method stamp information. This seems like it should be a fixable problem, and if so it would be very nice to see a standard format in circulation. I am not a GemStone user, but I am a long time admirer of GS after having encountered it in a project that I worked on at Ford Motor Company back in the 1990s. Since then I have been active in Squeak, and I would be very happy to see good interoperability between Squeak and GS. If Tonel can help with that, great. Dave On Wed, Aug 26, 2020 at 12:20:02PM -0700, Martin McClure wrote: > Hi all, > > Dale let me know this morning that Tonel was being discussed on > Squeak-dev.?? I beg your pardon for arriving late. > > As Dale said, I'm the minder of the Tonel 1.0 standard, which is > currently in draft, with initial feedback from some of the folks who > have implemented or are interested in implementing Tonel for their > Smalltalk dialect. > > I'm interested in getting feedback from *all* dialects who are > interested in using Tonel. I hope that the Squeak community will > participate. > > Tonel started as a collaboration between Pharo (primarily Esteban > Lorenzano) and GemTalk (primarily me), but the intent has always been to > have a format that can be used in common between *all* dialects of > Smalltalk. The fundamental shape of Tonel is probably not going to > change at this point, but feedback so far is likely to result in some > changes to the draft standard. > > Note that Tonel as currently implemented by Pharo is a bit different > from standard Tonel. Pharo has agreed to make several changes to the > format to standardize it. I'm not sure what the status of those changes > within the Pharo project. The GemStone implementation is closer to the > standard, though not fully there yet. > > I encourage the Squeak community to consider whether coding to the > standard early on might be a desirable direction. As Dale explained, the > standard does allow for dialect-specific properties, so adding > timestamps probably doesn't require any changes to the spec. > > I'd like it If a few folks from the community would volunteer to give > the spec a careful read-through and comment. It's a bit of a read (and > was quite a bit of effort to write!) so I won't post the draft on the > list, but it's available by request, and I need to figure out a place to > make it readily available. > > Regards, > -Martin > > > On 8/26/20 9:41 AM, Dale Henrichs wrote: > >Eliot, > > > >When you repost, could you make sure that you include a description of > >where the time stamps are stashed ... I'm assuming that you are adding > >it to the method properties (where the category is stashed) as I think > >that this is the right place, but it's always best not to guess:) > > > >The current crop of Tonel readers/writers do not necessarily do a good > >job of preserving, foreign data (IIRC, the convention is to add a > >platform prefix to the property name, which is the same convention > >used for class properties ... at GemStone we add a leading `gs_` to > >our property names), so until we can get all of the different Tonel > >readers/writers to preserve foreign properties (package, class and > >method) it will continue to be dicey business for preserving foreign > >properties in cross platform projects ... > > > >Monticello does not explicitly preserve foreign properties as the > >definitions get created from the native objects, so it takes some > >additional work to arrange to preserve foreign properties for > >packages, classes, and methods in the objects themselves. So it is > >worth considering what you will do with preserving foreign properties > >from other platforms. > > > >FWIW, I intend to support the preservation of foreign properties in > >Rowan (read that as "I haven't done that yet":) > > > >Finally, Martin McClure has started working on a spec for the next > >generation Tonel format ... to add a few missing pieces and tweak the > >format to make it possible to continue to evolve the Tonel format into > >the future in a somewhat sane way. If there are folks here in the > >Squeak community who would like to review, comment and participate in > >the creation of the next generation format, send me (or Martin) mail > >and we'll get you added to the mailing list. > > > >Dale > > > >On 8/26/20 7:15 AM, Eliot Miranda wrote: > >>Jakob, > >> > >>>On Aug 26, 2020, at 2:45 AM, Jakob Reschke > >>>wrote: > >>> > >>>???Hi Eliot, > >>> > >>>>Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda > >>>>: > >>>> > >>>>If we go with Tonel then we must change it to support method > >>>>timestamps.?? I have a change set that does this (it is a trivial > >>>>change).?? And my changes are controlled by a class variable so that > >>>>the same code can produce Pharo format or a slightly modified > >>>>format that includes method timestamps. > >>>> > >>>>What I don???t understand is why Esteban Lorenzano refuses to accept > >>>>my changes and allow Tonel to be used either with or without method > >>>>timestamps. > >>>> > >>>Method timestamps produce merge conflicts inevitably. > >>a) only when they change, and they change only when methods change > >>b) inadvertent method timestamp changes can be undone automatically > >>c) Squeak uses method timestamps; we have lots of tools that use > >>them. Dropping them just so that we can use Tonel is an example of > >>the tail wagging the dog. The Tonel interface must instead be made to > >>function with method timestamps > >> > >>If there is a decision not to support method timestamps then I will > >>not support the work. This is a make or break issue for me. > >> > >>>Can you re-post > >>>your changeset here? > >>I???ll post it later today (reading email in bed right now). > >> > >>>https://github.com/squeak-smalltalk/squeak-tonel/issues > >>OK > >> > >>>Then we could > >>>discuss whether to include it at least in the Squeak version. As we > >>>have heard from Mariano some time ago, VA Smalltalk also puts its > >>>dialect-specific metadata in the Tonel format, so Squeak would not be > >>>the first to do so. > >>Good. > >> > >>>Kind regards, > >>>Jakob > > > > From martin at hand2mouse.com Thu Aug 27 01:39:50 2020 From: martin at hand2mouse.com (Martin McClure) Date: Wed, 26 Aug 2020 18:39:50 -0700 Subject: [squeak-dev] Squeak, Tonel, and the Tonel standard In-Reply-To: References: <344D71FD-943D-4761-AEE0-A37EC3274174@gmail.com> <929db24b-03d4-2939-5057-e150370da05a@hand2mouse.com> Message-ID: <16d12dbf-b62e-2ec3-60a0-2b76b8df7aff@hand2mouse.com> Good question. Why a thing like Tonel, instead of just Smalltalk? The short answer is that Smalltalk doesn't have syntax for anything larger than a method. Filetree creates one file per method, so each file can be just Smalltalk. Filetree doesn't work well for large bodies of code -- operating systems tend to allocate a minimum of 4K to each file. Since most methods are *much* shorter than 4K, most of the space is unused. If you have a million methods (and some of my customers *do* have a million methods) the space requirements are prohibitive. The answer is to put more than one method into most files. When you start to pack more than one method into the same file, you need some kind of syntax beyond Smalltalk to tell you where each method begins and ends, and other meta-information like class definitions and whether a method is a class method or an instance method and what category it belongs in is also needed. Smalltalk doesn't have syntax for that. Tonel tries to keep the methods themselves as much pure Smalltalk and as readable as possible. The extra syntax is needed for the things outside the methods. Note that Tonel is *not* chunk format. Chunk format dates back to Smalltalk-80, and is not part of Tonel. No '!!' in Tonel files. :-) Chunk format did exist for a similar reason, though, that some kind of syntax beyond Smalltalk is needed if you want to put more than one method in a file. Chunk format  was imperative for the things outside of methods (things like class definitions are essentially do-its). This has led to serious awkwardness over the years, so Tonel is entirely declarative. Hope that helps, -Martin On 8/26/20 5:04 PM, Kjell Godo wrote: > i realize that you want to keep the ball rolling and all > and not waste the previous efforts > but why make a special Tonel syntax ? > why not just use Smalltalk and String literals Number literals etc > then it will be easy to change > and isn’t this whole chunk format > that shows up in Package Files > an artifact of the limited hardware of yor > or i can’t tell why they used it instead of just using Smalltalk > i can’t see why you wouldn’t just use Smalltalk instead of these ! ! > bang things > and all     are there some C style hard limits that can run you afoul ? > no there are not > but this is not helping to keep the ball rolling no > > On Wed, Aug 26, 2020 at 13:37 Martin McClure > wrote: > > Hi Jakob, > > Thanks for your interest. I'll send you the draft under separate > cover. > Putting it on GitHub is probably the best option -- I'll try to > get that > set up within the next couple of days, and announce it on the list > when > I do. > > Regards, > -Martin > > On 8/26/20 1:04 PM, Jakob Reschke wrote: > > Hello Martin, > > > > While I probably won't be able to provide comprehensive feedback or > > even read the whole text in the near future, I would certainly be > > interested to have a look. > > > > What is the licensing status of the draft and future proposed > > standard? If it is in some plain text/markup format, is it > possible to > > upload the draft to a public GitHub repository? Or something similar > > that allows for commenting on changes. On GitHub one can only > comment > > on diffs, but the initial commit will add all the lines, so one > could > > still comment on all of the text. Also people could provide > suggested > > changes via pull requests. > > > > Kind regards, > > Jakob > > > > Am Mi., 26. Aug. 2020 um 21:20 Uhr schrieb Martin McClure > > >: > >> Hi all, > >> > >> Dale let me know this morning that Tonel was being discussed on > >> Squeak-dev.  I beg your pardon for arriving late. > >> > >> As Dale said, I'm the minder of the Tonel 1.0 standard, which is > >> currently in draft, with initial feedback from some of the > folks who > >> have implemented or are interested in implementing Tonel for their > >> Smalltalk dialect. > >> > >> I'm interested in getting feedback from *all* dialects who are > >> interested in using Tonel. I hope that the Squeak community will > >> participate. > >> > >> Tonel started as a collaboration between Pharo (primarily Esteban > >> Lorenzano) and GemTalk (primarily me), but the intent has > always been to > >> have a format that can be used in common between *all* dialects of > >> Smalltalk. The fundamental shape of Tonel is probably not going to > >> change at this point, but feedback so far is likely to result > in some > >> changes to the draft standard. > >> > >> Note that Tonel as currently implemented by Pharo is a bit > different > >> from standard Tonel. Pharo has agreed to make several changes > to the > >> format to standardize it. I'm not sure what the status of those > changes > >> within the Pharo project. The GemStone implementation is closer > to the > >> standard, though not fully there yet. > >> > >> I encourage the Squeak community to consider whether coding to the > >> standard early on might be a desirable direction. As Dale > explained, the > >> standard does allow for dialect-specific properties, so adding > >> timestamps probably doesn't require any changes to the spec. > >> > >> I'd like it If a few folks from the community would volunteer > to give > >> the spec a careful read-through and comment. It's a bit of a > read (and > >> was quite a bit of effort to write!) so I won't post the draft > on the > >> list, but it's available by request, and I need to figure out a > place to > >> make it readily available. > >> > >> Regards, > >> -Martin > >> > >> > >> On 8/26/20 9:41 AM, Dale Henrichs wrote: > >>> Eliot, > >>> > >>> When you repost, could you make sure that you include a > description of > >>> where the time stamps are stashed ... I'm assuming that you > are adding > >>> it to the method properties (where the category is stashed) as > I think > >>> that this is the right place, but it's always best not to guess:) > >>> > >>> The current crop of Tonel readers/writers do not necessarily > do a good > >>> job of preserving, foreign data (IIRC, the convention is to add a > >>> platform prefix to the property name, which is the same convention > >>> used for class properties ... at GemStone we add a leading > `gs_` to > >>> our property names), so until we can get all of the different > Tonel > >>> readers/writers to preserve foreign properties (package, class and > >>> method) it will continue to be dicey business for preserving > foreign > >>> properties in cross platform projects ... > >>> > >>> Monticello does not explicitly preserve foreign properties as the > >>> definitions get created from the native objects, so it takes some > >>> additional work to arrange to preserve foreign properties for > >>> packages, classes, and methods in the objects themselves. So it is > >>> worth considering what you will do with preserving foreign > properties > >>> from other platforms. > >>> > >>> FWIW, I intend to support the preservation of foreign > properties in > >>> Rowan (read that as "I haven't done that yet":) > >>> > >>> Finally, Martin McClure has started working on a spec for the next > >>> generation Tonel format ... to add a few missing pieces and > tweak the > >>> format to make it possible to continue to evolve the Tonel > format into > >>> the future in a somewhat sane way. If there are folks here in the > >>> Squeak community who would like to review, comment and > participate in > >>> the creation of the next generation format, send me (or > Martin) mail > >>> and we'll get you added to the mailing list. > >>> > >>> Dale > >>> > >>> On 8/26/20 7:15 AM, Eliot Miranda wrote: > >>>> Jakob, > >>>> > >>>>> On Aug 26, 2020, at 2:45 AM, Jakob Reschke > > > >>>>> wrote: > >>>>> > >>>>> Hi Eliot, > >>>>> > >>>>>> Am Mi., 26. Aug. 2020 um 11:20 Uhr schrieb Eliot Miranda > >>>>>> >: > >>>>>> > >>>>>> If we go with Tonel then we must change it to support method > >>>>>> timestamps.  I have a change set that does this (it is a > trivial > >>>>>> change).  And my changes are controlled by a class variable > so that > >>>>>> the same code can produce Pharo format or a slightly modified > >>>>>> format that includes method timestamps. > >>>>>> > >>>>>> What I don’t understand is why Esteban Lorenzano refuses to > accept > >>>>>> my changes and allow Tonel to be used either with or > without method > >>>>>> timestamps. > >>>>>> > >>>>> Method timestamps produce merge conflicts inevitably. > >>>> a) only when they change, and they change only when methods > change > >>>> b) inadvertent method timestamp changes can be undone > automatically > >>>> c) Squeak uses method timestamps; we have lots of tools that use > >>>> them. Dropping them just so that we can use Tonel is an > example of > >>>> the tail wagging the dog. The Tonel interface must instead be > made to > >>>> function with method timestamps > >>>> > >>>> If there is a decision not to support method timestamps then > I will > >>>> not support the work. This is a make or break issue for me. > >>>> > >>>>> Can you re-post > >>>>> your changeset here? > >>>> I’ll post it later today (reading email in bed right now). > >>>> > >>>>> https://github.com/squeak-smalltalk/squeak-tonel/issues > >>>> OK > >>>> > >>>>> Then we could > >>>>> discuss whether to include it at least in the Squeak > version. As we > >>>>> have heard from Mariano some time ago, VA Smalltalk also > puts its > >>>>> dialect-specific metadata in the Tonel format, so Squeak > would not be > >>>>> the first to do so. > >>>> Good. > >>>> > >>>>> Kind regards, > >>>>> Jakob > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.gade at gmail.com Thu Aug 27 16:20:47 2020 From: eric.gade at gmail.com (Eric Gade) Date: Thu, 27 Aug 2020 12:20:47 -0400 Subject: [squeak-dev] UK Smalltalk User Group meeting - Wednesday, August 26th In-Reply-To: References: Message-ID: Hello all, Does anyone have a link to the recording for this event (if there was one)? Thanks On Tue, Aug 18, 2020 at 1:19 PM Vanessa Freudenberg wrote: > This should be interesting - Erik is using SqueakJS for the in-browser > component. > > - Vanessa - > > On Tue, Aug 18, 2020 at 3:15 AM Giovanni Corriga > wrote: > >> The next meeting of the UK Smalltalk User Group will be on Wednesday, >> August 26th. >> In this meeting, Erik Stel will present his current project - >> CodeParadise. >> >> CodeParadise is a cloud based platform (to be) to learn to program using >> Object Oriented principles within a Smalltalk environment. >> CodeParadise is still in very early development, but some of its results >> have seen interest from the community. Therefore a presentation will >> provide insight in the design, current status, and possibilities of the >> results so far. >> The discussion afterwards can be used for both in-depth technical topics >> as well as the more philosophical topics about programming (as warmth >> and/or beer consumption will guide us). >> >> Given the current COVID-19 restrictions, this will be an online meeting >> from home. >> If you'd like to join us, please sign up in advance on the meeting's >> Meetup page https://www.meetup.com/UKSTUG/events/cbklbrybclbjc/ to >> receive the meeting details. >> >> Don’t forget to bring your laptop and drinks! >> >> Cheers, >> >> Giovanni >> >> > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From commits at source.squeak.org Thu Aug 27 17:32:20 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 27 Aug 2020 17:32:20 0000 Subject: [squeak-dev] The Trunk: TrueType-tonyg.54.mcz Message-ID: Tony Garnock-Jones uploaded a new version of TrueType to project The Trunk: http://source.squeak.org/trunk/TrueType-tonyg.54.mcz ==================== Summary ==================== Name: TrueType-tonyg.54 Author: tonyg Time: 27 August 2020, 7:31:31.535357 pm UUID: d4f009fe-48ef-40dc-9455-30140dfcbaf6 Ancestors: TrueType-mt.53 In order for pixelsPerInchChanged to properly rerender things, it seems the (previously-unused) functionality of flushCachedValues is required. So this change puts the functionality of flushCachedValues in flushCache, removes flushCachedValues (no callers in the trunk image), and alters pixelsPerInchChanged for TTCFont to call flushCache instead of recreateCache. =============== Diff against TrueType-mt.53 =============== Item was changed: ----- Method: TTCFont>>flushCache (in category 'initialize') ----- flushCache "Flush the cache of this font" + cache := foregroundColor := colorToCacheMap := nil. + + "Flush all values computed from ttcDescription and cached for speed" + height := ascent := descent := nil.! - cache := foregroundColor := colorToCacheMap := nil.! Item was removed: - ----- Method: TTCFont>>flushCachedValues (in category 'private') ----- - flushCachedValues - "Flush all values computed from ttcDescription and cached for speed" - "TTCFont allInstancesDo:[:font| font flushCachedValues]" - height := ascent := descent := nil.! Item was changed: ----- Method: TTCFont>>pixelsPerInchChanged (in category 'notifications') ----- pixelsPerInchChanged "The definition of TextStyle class>>pixelsPerInch has changed. Do whatever is necessary." + self flushCache! - self recreateCache! From commits at source.squeak.org Thu Aug 27 17:33:18 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Thu, 27 Aug 2020 17:33:18 0000 Subject: [squeak-dev] The Trunk: Graphics-tonyg.438.mcz Message-ID: Tony Garnock-Jones uploaded a new version of Graphics to project The Trunk: http://source.squeak.org/trunk/Graphics-tonyg.438.mcz ==================== Summary ==================== Name: Graphics-tonyg.438 Author: tonyg Time: 27 August 2020, 7:33:11.682629 pm UUID: c77170e1-f29b-44f5-bb2d-b1dc78f9e60c Ancestors: Graphics-pre.437 As the display may need a repaint after pixelsPerInch changes, call Display restore. =============== Diff against Graphics-pre.437 =============== Item was changed: ----- Method: TextStyle class>>pixelsPerInch: (in category 'utilities') ----- pixelsPerInch: aNumber "Set the nominal number of pixels per inch to aNumber." TextConstants at: #pixelsPerInch put: aNumber asFloat. + AbstractFont allSubInstancesDo: [ :font | font pixelsPerInchChanged ]. + Display restore.! - AbstractFont allSubInstancesDo: [ :font | font pixelsPerInchChanged ].! From tonyg at leastfixedpoint.com Thu Aug 27 17:57:09 2020 From: tonyg at leastfixedpoint.com (Tony Garnock-Jones) Date: Thu, 27 Aug 2020 19:57:09 +0200 Subject: [squeak-dev] TTCFont >> flushCachedValues In-Reply-To: <93602a53-09f8-b358-4436-b51b90d7d650@leastfixedpoint.com> References: <93602a53-09f8-b358-4436-b51b90d7d650@leastfixedpoint.com> Message-ID: I committed those changes. Next: should TextStyle class >> pixelsPerInch be moved to DisplayScreen >> pixelsPerInch ? If so: TextPrinter >> defaultResolution is probably wrong, and should probably just answer some constant like 300dpi...? ;;-- If, after loading the recent changes to pixelsPerInch: etc., you want to see their effect, try this: 1. | s | s := TextStyle named: #BitstreamVeraSans. UserInterfaceTheme current properties associationsDo: [:a | (a value isKindOf: StrikeFont) ifTrue: [ s addNewFontSize: a value pointSize. a value: (s fontOfPointSize: a value pointSize)]]. 2. Close and reopen all your widgets (sigh), including running TheWorldMainDockingBar initialize 3. Open a few windows 4. Alternate between the following: TextStyle pixelsPerInch: 163 TextStyle pixelsPerInch: 96 Cheers, Tony On 8/26/20 4:20 PM, Tony Garnock-Jones wrote: > Hi all, > > I'm looking at the image-side DPI-change code, namely TextStyle >> > pixelsPerInch:. > > The broadcast of the change is fine. But the handler in TTCFont is > subtly wrong, I think. > > - I believe instance variables height, ascent, descent have to be nil'd > as part of pixelsPerInchChanged. Is that right? Without nil'ing them, > my TTCFonts don't resize properly. > > - This suggests flushCachedValues, which has NO SENDERS (!), should be > folded into flushCache. Does that sound right? > > - Finally, if both the above hold, then pixelsPerInchChanged should be > calling flushCache instead of recreateCache. Does that sound right? > > I'll be running for a few days with these changes in my image, to see if > there are any obvious problems with them. > > But, before I push a commit out to Trunk, if I could get a thumbs-up > from someone who knows a bit about the font subsystem, that'd be great! > > Regards, > Tony > From tonyg at leastfixedpoint.com Thu Aug 27 18:42:30 2020 From: tonyg at leastfixedpoint.com (Tony Garnock-Jones) Date: Thu, 27 Aug 2020 20:42:30 +0200 Subject: [squeak-dev] Squeak on a PostmarketOS cellphone Message-ID: Hi all, I've recently been playing with Squeak running on a PostmarketOS phone (Samsung Galaxy S7). Many thanks to those who recently landed the ARMv8 build of Cog. (Per the commit history I think the main person responsible was Ken Dickey? Thanks Ken!) I wrote about progress so far here: https://eighty-twenty.org/2020/08/25/postmarketos-smalltalk Today I posted an update with a saner DPI setting for the phone's display: https://eighty-twenty.org/2020/08/27/squeak-postmarketos-update Next on the list is to read touchscreen input from /dev/input/event1! Cheers, Tony From jrmaffeo at gmail.com Thu Aug 27 21:43:47 2020 From: jrmaffeo at gmail.com (John-Reed Maffeo) Date: Thu, 27 Aug 2020 14:43:47 -0700 Subject: [squeak-dev] Squeak on a PostmarketOS cellphone In-Reply-To: References: Message-ID: Tony, What a great project! Keep up the good work! I look forward to seeing your progress. Do you think you may be able to get to the "Watson, come here ..." phase? -jrm On Thu, Aug 27, 2020 at 11:42 AM Tony Garnock-Jones < tonyg at leastfixedpoint.com> wrote: > Hi all, > > I've recently been playing with Squeak running on a PostmarketOS phone > (Samsung Galaxy S7). > > Many thanks to those who recently landed the ARMv8 build of Cog. (Per > the commit history I think the main person responsible was Ken Dickey? > Thanks Ken!) > > I wrote about progress so far here: > https://eighty-twenty.org/2020/08/25/postmarketos-smalltalk > > Today I posted an update with a saner DPI setting for the phone's > display: https://eighty-twenty.org/2020/08/27/squeak-postmarketos-update > > Next on the list is to read touchscreen input from /dev/input/event1! > > Cheers, > Tony > > -- John-Reed Maffeo -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyg at leastfixedpoint.com Thu Aug 27 22:00:40 2020 From: tonyg at leastfixedpoint.com (Tony Garnock-Jones) Date: Fri, 28 Aug 2020 00:00:40 +0200 Subject: [squeak-dev] Squeak on a PostmarketOS cellphone In-Reply-To: References: Message-ID: On 8/27/20 11:43 PM, John-Reed Maffeo wrote: > Tony, > What a great project! Keep up the good work! I look forward to seeing > your progress. Do you think you may be able to get to the "Watson, come > here ..." phase? I think so! The old Erlang code had a modem control actor that was fleshed-out enough to make and take calls, and to send and receive SMS. It was a bit of a blast from the past making it send "ATD..." etc :-) (See for example https://github.com/tonyg/erlang-openmoko/blob/a314ac9d908b156ffd35cff8ab259787a06f3c46/src/openmoko_callmanager.erl#L102-L106) Cheers, Tony From marcel.taeumel at hpi.de Fri Aug 28 08:42:00 2020 From: marcel.taeumel at hpi.de (Marcel Taeumel) Date: Fri, 28 Aug 2020 10:42:00 +0200 Subject: [squeak-dev] TTCFont >> flushCachedValues In-Reply-To: References: <93602a53-09f8-b358-4436-b51b90d7d650@leastfixedpoint.com> Message-ID: Hi Tony. Maybe also take a look at: Preferences class >> #setDemoFonts Preferences class >> #setDefaultFonts: UserInterfaceTheme >> #applyAfter: It is possible to see the effects of your changes without closing all your widgets. Just use #apply or #applyAfter:. Best, Marcel Am 27.08.2020 19:57:17 schrieb Tony Garnock-Jones : I committed those changes. Next: should TextStyle class >> pixelsPerInch be moved to DisplayScreen >> pixelsPerInch ? If so: TextPrinter >> defaultResolution is probably wrong, and should probably just answer some constant like 300dpi...? ;;-- If, after loading the recent changes to pixelsPerInch: etc., you want to see their effect, try this: 1. | s | s := TextStyle named: #BitstreamVeraSans. UserInterfaceTheme current properties associationsDo: [:a | (a value isKindOf: StrikeFont) ifTrue: [ s addNewFontSize: a value pointSize. a value: (s fontOfPointSize: a value pointSize)]]. 2. Close and reopen all your widgets (sigh), including running TheWorldMainDockingBar initialize 3. Open a few windows 4. Alternate between the following: TextStyle pixelsPerInch: 163 TextStyle pixelsPerInch: 96 Cheers, Tony On 8/26/20 4:20 PM, Tony Garnock-Jones wrote: > Hi all, > > I'm looking at the image-side DPI-change code, namely TextStyle >> > pixelsPerInch:. > > The broadcast of the change is fine. But the handler in TTCFont is > subtly wrong, I think. > > - I believe instance variables height, ascent, descent have to be nil'd > as part of pixelsPerInchChanged. Is that right? Without nil'ing them, > my TTCFonts don't resize properly. > > - This suggests flushCachedValues, which has NO SENDERS (!), should be > folded into flushCache. Does that sound right? > > - Finally, if both the above hold, then pixelsPerInchChanged should be > calling flushCache instead of recreateCache. Does that sound right? > > I'll be running for a few days with these changes in my image, to see if > there are any obvious problems with them. > > But, before I push a commit out to Trunk, if I could get a thumbs-up > from someone who knows a bit about the font subsystem, that'd be great! > > Regards, > Tony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.dickey at whidbey.com Fri Aug 28 14:17:18 2020 From: ken.dickey at whidbey.com (ken.dickey at whidbey.com) Date: Fri, 28 Aug 2020 07:17:18 -0700 Subject: [squeak-dev] Thank Eliot Miranda! Message-ID: > Many thanks to those who recently landed the ARMv8 build of Cog. (Per the commit history I think the main person responsible was Ken Dickey? Thanks Ken!) That was 99.997% Eliot. I just got the vm-display-fbdev up with libevdev on Raspi3/4 & LePotato. Great thanks to Eliot !!! -KenD From eliot.miranda at gmail.com Fri Aug 28 17:08:04 2020 From: eliot.miranda at gmail.com (Eliot Miranda) Date: Fri, 28 Aug 2020 10:08:04 -0700 Subject: [squeak-dev] Thank Eliot Miranda! In-Reply-To: References: Message-ID: Hi Ken, Hi Tony, Hi All, On Fri, Aug 28, 2020 at 7:26 AM wrote: > > Many thanks to those who recently landed the ARMv8 build of Cog. (Per > the commit history I think the main person responsible was Ken Dickey? > Thanks Ken!) > > That was 99.997% Eliot. I just got the vm-display-fbdev up with > libevdev on Raspi3/4 & LePotato. > Ken, it feels to me much closer to 50/50. You actually wrote the code and did the testing to get the FFI working. Yes I helped you because it's my framework and my architecture, but you learned it and made it work. But you *were* & *are* instrumental in realizing the ARMv8 VM. Thank you. In fact I'm extending your structs-passed-in-registers code right now to cope with HFAs (homogenous float arrays with four or fewer elements). Once we have the JIT fully working then I can take some more credit, but you've supported me with crucial testing. Great thanks to Eliot !!! > and to Ken!! > -KenD > _,,,^..^,,,_ best, Eliot -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlramberg at gmail.com Fri Aug 28 23:02:05 2020 From: karlramberg at gmail.com (karl ramberg) Date: Sat, 29 Aug 2020 01:02:05 +0200 Subject: [squeak-dev] Thank Eliot Miranda! In-Reply-To: References: Message-ID: Thanks all for great work :-D Best, Karl On Fri, 28 Aug 2020 at 19:08, Eliot Miranda wrote: > Hi Ken, Hi Tony, Hi All, > > On Fri, Aug 28, 2020 at 7:26 AM wrote: > >> > Many thanks to those who recently landed the ARMv8 build of Cog. (Per >> >> >> the commit history I think the main person responsible was Ken Dickey? >> >> >> Thanks Ken!) >> >> >> >> >> >> That was 99.997% Eliot. I just got the vm-display-fbdev up with >> >> >> libevdev on Raspi3/4 & LePotato. >> > > Ken, it feels to me much closer to 50/50. You actually wrote the code and > did the testing to get the FFI working. Yes I helped you because it's my > framework and my architecture, but you learned it and made it work. But > you *were* & *are* instrumental in realizing the ARMv8 VM. Thank you. In > fact I'm extending your structs-passed-in-registers code right now to cope > with HFAs (homogenous float arrays with four or fewer elements). Once we > have the JIT fully working then I can take some more credit, but you've > supported me with crucial testing. > > Great thanks to Eliot !!! >> > > and to Ken!! > > >> -KenD >> > > _,,,^..^,,,_ > best, Eliot > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirtai+st at gmail.com Sun Aug 30 00:07:25 2020 From: kirtai+st at gmail.com (Douglas Brebner) Date: Sun, 30 Aug 2020 01:07:25 +0100 Subject: [squeak-dev] Squeak on a PostmarketOS cellphone In-Reply-To: References: Message-ID: <06ac175a-acb9-7045-a77c-a46d65ca0936@gmail.com> On 27/08/2020 19:42, Tony Garnock-Jones wrote: > Hi all, > > I've recently been playing with Squeak running on a PostmarketOS phone > (Samsung Galaxy S7). Oh wow, I've been looking at PostmarketOS phones with Plasma Mobile recently, but a Smalltalk based phone would be amazing. From builds at travis-ci.org Sun Aug 30 14:51:47 2020 From: builds at travis-ci.org (Travis CI) Date: Sun, 30 Aug 2020 14:51:47 +0000 Subject: [squeak-dev] [CRON] Broken: squeak-smalltalk/squeak-app#1810 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f4bbd0585ce4_13f935341aebc14432@travis-tasks-7d9cbd494c-r827t.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1810 Status: Broken Duration: 10 mins and 22 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/722482542?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Sun Aug 30 19:07:46 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Sun, 30 Aug 2020 15:07:46 -0400 Subject: [squeak-dev] [lewis@mail.msen.com: [Pharo-dev] OSProcess and CommandShell updated on GitHub for Pharo] Message-ID: <20200830190746.GB44231@shell.msen.com> I spent a couple of hours this afternoon doing an export of the latest OSProcess/CommandShell packages to a couple of GitHub repositories for benefit of Pharo users. The updates have been available for Squeak for some time, since I do all development in Squeak and use SqueakSource as the upstream repository. But I'm not sure that I ever bothered mentioning it on the list here. So in case it may be of interest, here is a recently added feature that may be of some general usefulness: OSProcess outputOf: 'ls -lR | wc -l' This is a convenience method that handles parsing, piping, and error handling for a unix-style command pipeline. Both OSProcess and CommandShell must be loaded. Any errors detected in the external commands will be displayed in a Squeak debugger. If that happens, proceed through the debugger to obtain the final stdout result. OSProcess/CommandShell can be loaded with the SqueakMap package loader, or: Installer ss project: 'OSProcess'; install: 'OSProcess'. Installer ss project: 'CommandShell'; install: 'CommandShell'. Dave ----- Forwarded message from "David T. Lewis" ----- Date: Sun, 30 Aug 2020 14:38:44 -0400 From: "David T. Lewis" To: pharo-dev at lists.pharo.org Subject: [Pharo-dev] OSProcess and CommandShell updated on GitHub for Pharo These updates bring OSProcess/CommandShell up to date with the latest development versions, and include earlier fixes for Pharo by Max Leske. The repositories are at https://github.com/dtlewis290/OSProcess-Tonel https://github.com/dtlewis290/CommandShell-Tonel A new feature of possible interest is: OSProcess outputOf: 'ls -lR | wc -l' This is a convenience method that handles parsing, piping, and error handling for a unix-style command pipeline. Both OSProcess and CommandShell must be loaded. Any errors detected in the external commands will be displayed in a Pharo debugger, proceed through the debugger to obtain the final stdout result. Dave ----- End forwarded message ----- From commits at source.squeak.org Sun Aug 30 23:54:13 2020 From: commits at source.squeak.org (commits at source.squeak.org) Date: Sun, 30 Aug 2020 23:54:13 0000 Subject: [squeak-dev] The Inbox: WebClient-Core-ct.124.mcz Message-ID: Christoph Thiede uploaded a new version of WebClient-Core to project The Inbox: http://source.squeak.org/inbox/WebClient-Core-ct.124.mcz ==================== Summary ==================== Name: WebClient-Core-ct.124 Author: ct Time: 31 August 2020, 1:54:11.685896 am UUID: b0d7790c-c195-6e4d-ad0f-fce8cf8b3b00 Ancestors: WebClient-Core-ul.123 Fixes a syntax error in multipart/form-data encoding Phew! It costed me a few hours to track some higher-level application bug down to this low level code ... =============== Diff against WebClient-Core-ul.123 =============== Item was changed: ----- Method: WebUtils class>>encodeMultipartForm:boundary: (in category 'decoding') ----- encodeMultipartForm: fieldMap boundary: boundary "Encodes the fieldMap as multipart/form-data. The fieldMap may contain MIMEDocument instances to indicate the presence of a file to upload to the server. If the MIMEDocument is present, its content type and file name will be used for the upload. The fieldMap can be EITHER an array of associations OR a Dictionary of key value pairs (the former is useful for providing multiple fields and/or specifying the order of fields)." ^String streamContents:[:stream| (fieldMap as: Dictionary) keysAndValuesDo:[:fieldName :fieldValue | | fieldContent | "Write multipart boundary and common headers" stream nextPutAll: '--', boundary; crlf. stream nextPutAll: 'Content-Disposition: form-data; name="', fieldName, '"'. "Figure out if this is a file upload" (fieldValue isKindOf: MIMEDocument) ifTrue:[ + stream nextPutAll: '; filename="', fieldValue url pathForFile, '"'; crlf. - stream nextPutAll: ' filename="', fieldValue url pathForFile, '"'; crlf. stream nextPutAll: 'Content-Type: ', fieldValue contentType. fieldContent := (fieldValue content ifNil:[ (FileStream readOnlyFileNamed: fieldValue url pathForFile) contentsOfEntireFile. ]) asString. ] ifFalse: [fieldContent := fieldValue]. stream crlf; crlf. stream nextPutAll: fieldContent asString. stream crlf. ]. stream nextPutAll: '--', boundary, '--', String crlf. ]. ! From stes at telenet.be Mon Aug 31 07:09:28 2020 From: stes at telenet.be (stes@PANDORA.BE) Date: Mon, 31 Aug 2020 09:09:28 +0200 (CEST) Subject: [squeak-dev] SQUEAK_SPY and -spy option Message-ID: <1040300227.101031863.1598857768961.JavaMail.zimbra@telenet.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I've already asked this question on vm-dev, with no replies so far. Perhaps someone knows here on this list ... I wonder whether anyone is using the SQUEAK_SPY environment variable, or knows what this is doing. In the VM source code : platforms/unix/vm-display-X11/sqUnixX11.c:int withSpy= 0; platforms/unix/vm-display-X11/sqUnixX11.c: if (getenv("SQUEAK_SPY")) withSpy= 1; platforms/unix/vm/sqUnixMain.c: int withSpy= 0; platforms/unix/vm/sqUnixMain.c: else if (!strcmp(argv[0], VMOPTION("spy"))) { withSpy = 1; return 1; } Also I wonder why both .c files (sqUnixX11.c and sqUnixMain.c) both define the same global variable (they both define withSpy). Maybe the VM -spy option is somehow related to spyOn: and MessageTally ?? http://wiki.squeak.org/squeak/4210 It's just a guess. I don't immediately see any documentation on this on wiki.squeak.org. Perhaps -spy is related to Squeak Performance Tuning ? Is anyone using -spy or SQUEAK_SPY ? David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJfTKHkAAoJEAwpOKXMq1MaHqoH/Ar6sReeDUhwcWDPWCyWupIc 07gQMUEcM2rUa3hZCysoGQGJGPH7ZXNEj8QViW4QIwrAnR0j6GGz9M648rOot9IF 9yH3TEFmPk4hCYq8UADyfxFRpEBs9dOKk3TVE0LLIo1KTWqyo+Fz4SYQQFWQnfZ2 5lXVwbDJlfFyBOvGaNCAzFgoftWSL1KhxEsGuhPKo1b2WO++T9rNVF4eSvlKltJR 5rr/bmuOC0ILYcDBe0+wsYg5O17DdSMPRSeKBgwqlnMS6xquxfS90VS7J1uH6wC3 Qe+fDeaDJxHZ05+aEL8aSAMhKiGfm5oBOc07gVxYO20otmWt9sTgaGhY1+3QEZo= =RR59 -----END PGP SIGNATURE----- From builds at travis-ci.org Mon Aug 31 15:06:08 2020 From: builds at travis-ci.org (Travis CI) Date: Mon, 31 Aug 2020 15:06:08 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1811 (squeak-trunk - 25ebaf1) In-Reply-To: Message-ID: <5f4d11df851cb_13f853b3d73cc26357@travis-tasks-f84bd69-dmp2x.mail> Build Update for squeak-smalltalk/squeak-app ------------------------------------- Build: #1811 Status: Errored Duration: 24 mins and 38 secs Commit: 25ebaf1 (squeak-trunk) Author: Marcel Taeumel Message: Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] View the changeset: https://github.com/squeak-smalltalk/squeak-app/compare/fb55517f583fe544f9225413a23fe82a680200c2...25ebaf18249322227da1f7c767384cb35082fab7 View the full build log and details: https://travis-ci.org/github/squeak-smalltalk/squeak-app/builds/722758820?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the squeak-smalltalk/squeak-app repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=8901856&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christoph.Thiede at student.hpi.uni-potsdam.de Mon Aug 31 15:16:57 2020 From: Christoph.Thiede at student.hpi.uni-potsdam.de (Thiede, Christoph) Date: Mon, 31 Aug 2020 15:16:57 +0000 Subject: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1811 (squeak-trunk - 25ebaf1) In-Reply-To: <5f4d11df851cb_13f853b3d73cc26357@travis-tasks-f84bd69-dmp2x.mail> References: , <5f4d11df851cb_13f853b3d73cc26357@travis-tasks-f84bd69-dmp2x.mail> Message-ID: <1761d723bd224dc49e6b872a5c68d0f2@student.hpi.uni-potsdam.de> Wow, today's error log is indeed worth a look: https://travis-ci.org/github/squeak-smalltalk/squeak-app/jobs/722758827 I perceived similar issues from time to time in my images before I wrote System-ct.1136 (Inbox) - maybe we should merge it to get around of these errors. Best, Christoph ________________________________ Von: Squeak-dev im Auftrag von Travis CI Gesendet: Montag, 31. August 2020 17:06:08 An: squeak-dev at lists.squeakfoundation.org Betreff: [squeak-dev] [CRON] Errored: squeak-smalltalk/squeak-app#1811 (squeak-trunk - 25ebaf1) squeak-smalltalk / squeak-app [branch icon]squeak-trunk [build has errored] Build #1811 has errored [arrow to build time] [clock icon]24 mins and 38 secs [Marcel Taeumel avatar]Marcel Taeumel 25ebaf1 CHANGESET → Hi all! The project "squeak-app" is part of the continuous build infrastructure (short: CI) for Squeak's bundles, which you can download at https://files.squeak.org/, followed by the version tag you are looking for. All bundles are updated on a regular basis, which is daily for Trunk (i.e. the current alpha version) and monthly for release versions. Note that there won't be new bundles if Squeak's build number, which reflects in-image code updates, did not change between CI jobs. -- The Squeak Oversight Board [ci skip] Want to know about upcoming build environment updates? Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you! SIGN UP HERE [book icon] Documentation about Travis CI Have any questions? We're here to help. Unsubscribe from build emails from the squeak-smalltalk/squeak-app repository. To unsubscribe from all build emails, please update your settings. [black and white travis ci logo] Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy Jacops | Contact: contact at travis-ci.com | Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz: DE282002648 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewis at mail.msen.com Mon Aug 31 19:16:13 2020 From: lewis at mail.msen.com (David T. Lewis) Date: Mon, 31 Aug 2020 15:16:13 -0400 Subject: [squeak-dev] SQUEAK_SPY and -spy option In-Reply-To: <1040300227.101031863.1598857768961.JavaMail.zimbra@telenet.be> References: <1040300227.101031863.1598857768961.JavaMail.zimbra@telenet.be> Message-ID: <20200831191613.GA78215@shell.msen.com> It looks like dead code to me. It sets a variable that is no longer referenced. My guess would be that it sets a flag that Ian used in early development of the Unix Squeak VM, possibly it was related to the jitter VMs that he was doing in early days. You can see the option being set in the sqUnixMain.c module back in 2003: http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/unix/vm/sqUnixMain.c?revision=620&view=markup Earlier version control for the VM was kept on SourceForge, I don't know if that is still available for historical purposes. In any case, as far as I can tell it is just an option setting that once meant something, but that has not been used for a long time. Dave On Mon, Aug 31, 2020 at 09:09:28AM +0200, stes at PANDORA.BE wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > I've already asked this question on vm-dev, with no replies so far. > > Perhaps someone knows here on this list ... > > I wonder whether anyone is using the SQUEAK_SPY environment variable, > or knows what this is doing. > > In the VM source code : > > platforms/unix/vm-display-X11/sqUnixX11.c:int withSpy= 0; > platforms/unix/vm-display-X11/sqUnixX11.c: if (getenv("SQUEAK_SPY")) withSpy= 1; > platforms/unix/vm/sqUnixMain.c: int withSpy= 0; > platforms/unix/vm/sqUnixMain.c: else if (!strcmp(argv[0], VMOPTION("spy"))) { withSpy = 1; return 1; } > > Also I wonder why both .c files (sqUnixX11.c and sqUnixMain.c) both define > the same global variable (they both define withSpy). > > Maybe the VM -spy option is somehow related to spyOn: and MessageTally ?? > > http://wiki.squeak.org/squeak/4210 > > It's just a guess. > I don't immediately see any documentation on this on wiki.squeak.org. > > Perhaps -spy is related to Squeak Performance Tuning ? > > Is anyone using -spy or SQUEAK_SPY ? > > David Stes > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJfTKHkAAoJEAwpOKXMq1MaHqoH/Ar6sReeDUhwcWDPWCyWupIc > 07gQMUEcM2rUa3hZCysoGQGJGPH7ZXNEj8QViW4QIwrAnR0j6GGz9M648rOot9IF > 9yH3TEFmPk4hCYq8UADyfxFRpEBs9dOKk3TVE0LLIo1KTWqyo+Fz4SYQQFWQnfZ2 > 5lXVwbDJlfFyBOvGaNCAzFgoftWSL1KhxEsGuhPKo1b2WO++T9rNVF4eSvlKltJR > 5rr/bmuOC0ILYcDBe0+wsYg5O17DdSMPRSeKBgwqlnMS6xquxfS90VS7J1uH6wC3 > Qe+fDeaDJxHZ05+aEL8aSAMhKiGfm5oBOc07gVxYO20otmWt9sTgaGhY1+3QEZo= > =RR59 > -----END PGP SIGNATURE----- > From ken.dickey at whidbey.com Mon Aug 31 19:35:37 2020 From: ken.dickey at whidbey.com (ken.dickey at whidbey.com) Date: Mon, 31 Aug 2020 12:35:37 -0700 Subject: [squeak-dev] Thank Eliot Miranda! Message-ID: <233053490b29360eb19088df3fd77b99@whidbey.com> Thanks for the kind words, Eliot. I think a better metaphor is adding a few grains of sand to the scale at the right time to tip the balance. :) Being part of a community means you don't have to do absolutely everything yourself. Glad to help out. -KenD From asqueaker at gmail.com Mon Aug 31 22:28:58 2020 From: asqueaker at gmail.com (Chris Muller) Date: Mon, 31 Aug 2020 17:28:58 -0500 Subject: [squeak-dev] The Inbox: WebClient-Core-ct.124.mcz In-Reply-To: References: Message-ID: I'm not qualified to review the change but good dig! :) On Sun, Aug 30, 2020 at 6:54 PM wrote: > > Christoph Thiede uploaded a new version of WebClient-Core to project The Inbox: > http://source.squeak.org/inbox/WebClient-Core-ct.124.mcz > > ==================== Summary ==================== > > Name: WebClient-Core-ct.124 > Author: ct > Time: 31 August 2020, 1:54:11.685896 am > UUID: b0d7790c-c195-6e4d-ad0f-fce8cf8b3b00 > Ancestors: WebClient-Core-ul.123 > > Fixes a syntax error in multipart/form-data encoding > > Phew! It costed me a few hours to track some higher-level application bug down to this low level code ... > > =============== Diff against WebClient-Core-ul.123 =============== > > Item was changed: > ----- Method: WebUtils class>>encodeMultipartForm:boundary: (in category 'decoding') ----- > encodeMultipartForm: fieldMap boundary: boundary > "Encodes the fieldMap as multipart/form-data. > > The fieldMap may contain MIMEDocument instances to indicate the presence > of a file to upload to the server. If the MIMEDocument is present, its > content type and file name will be used for the upload. > > The fieldMap can be EITHER an array of associations OR a Dictionary of > key value pairs (the former is useful for providing multiple fields and/or > specifying the order of fields)." > > ^String streamContents:[:stream| > (fieldMap as: Dictionary) keysAndValuesDo:[:fieldName :fieldValue | | fieldContent | > "Write multipart boundary and common headers" > stream nextPutAll: '--', boundary; crlf. > stream nextPutAll: 'Content-Disposition: form-data; name="', fieldName, '"'. > "Figure out if this is a file upload" > (fieldValue isKindOf: MIMEDocument) ifTrue:[ > + stream nextPutAll: '; filename="', fieldValue url pathForFile, '"'; crlf. > - stream nextPutAll: ' filename="', fieldValue url pathForFile, '"'; crlf. > stream nextPutAll: 'Content-Type: ', fieldValue contentType. > fieldContent := (fieldValue content ifNil:[ > (FileStream readOnlyFileNamed: fieldValue url pathForFile) contentsOfEntireFile. > ]) asString. > ] ifFalse: [fieldContent := fieldValue]. > stream crlf; crlf. > stream nextPutAll: fieldContent asString. > stream crlf. > ]. > stream nextPutAll: '--', boundary, '--', String crlf. > ]. > ! > >