April 2023 - Pharo-users - lists.pharo.org

Re: Picking neighbouring elements

by Steffen MÃ¤rcker

Hi Richard, Now that's much clearer to me: min{y | y in c . y > x} "strict supremum" max{y | y in c . y < x} "strict infimum" For the general case of a sequence (not sorted) of elements we can do strictSupremumOf: x in: sequence ^(sequence transduce filter: [:y | y > x]) "virtual sequence" inject: nil into: [:min :b | min ifNotNil: [:a | a min: b]] I just picked a variant of minimum that answers nil if no element is found. Other variants would work, too. The focus of transducers is on re-use and composition of processing steps. We can break this up into steps if needed: minimum := [:min :b | min ifNotNil: [:a | a min: b]] init: nil. "reduction" upperBounds := Filter predicate: [:y | y > x]. "transducer" strictSup := minimum transduce: upperBounds. "transformed reduction" ^strictSup reduce: sequence We can also use a different notation similar to a data flow: minimum <~ upperBounds <~ sequence Of course, if we know how the sequence is sorted, we should use another algorithm. Assuming an ascending order with no random access, we'd change minimum to stop early: minimum := [:min :b | Stop result: b]. Kind regards, Steffen Richard O'Keefe schrieb am Freitag, 21. April 2023 05:33:44 (+02:00): successor of x in c = the smallest element of c that is larger than x min {y | y in c . y > x} predecessor of x in c = the largest element of c that is smaller than x max {y | y in c . y < x} On Thu, 20 Apr 2023 at 21:08, Steffen MÃ¤rcker <merkste(a)web.de> wrote: Dear Richard, thanks for that additional piece. I'll put insert-<left/right> on my list of possible variants. I think we come back to naming after the initial port is done and everyone can play with it. Generally, I made the observation to better be careful with names since it's too easy to alienate other or trigger wrong assumptions. New topic! (quote below) Honestly, my knowledge of Haskell is rather limited and rusted. Hence, I am having difficulties understanding what exactly these operations with a sequence of elements. Can you give an example or some pseude/smalltalk code from your use-case and library? Kind regards Changing the subject a wee bit, there's an operation family in my library, and I wonder how it would fit into Transducers? To avoid bias, here's a specification in Haskell (for lists, because I haven't had any luck installing Data.Witherable). uccessorBy, predecessorBy :: (a -> a -> Ordering) -> a -> [a] -> a successor, predecessor :: Ord a => a -> [a] -> a successor = successorBy compare successorBy cmp x = minimumBy cmp . filter (\y -> cmp x y == LT) predecessor = predecessorBy compare predecessorBy cmp = successorBy (flip cmp) The reason these operations exist is to pick neighbouring elements in SortedCollections and SortedSets. But they make *sense* for any Enumerable. So there are "generic" definitions with orderrides for those two classes. A filter + a reduce . Traditionally, a #select:thenFold:ifNone: in order to avoid building an intermediate collection. That much I see how to do with transducers. But you can't get the desired override for #successor:[sortBlock:][ifNone:] by overriding #select:thenFold:ifNone: in SortedCollection or SortedSet. So what *should* one do? -- Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos unter vivaldi.com herunter

April 21, 2023

This week (16/2023) on the Pharo Issue Tracker

by Marcus Denker

We merged ~60 PRs this week. # Pharo 11 - Backport #13426: Make protocol of super method a priority in MethodClassifier #13432 https://github.com/pharo-project/pharo/pull/13432 - Use fixed spec version for Pharo 11 #13445 https://github.com/pharo-project/pharo/pull/13445 ## GIT/Iceberg (for Pharo 12, too) - 1279 merge menu should indicate the sense of the action #1680 https://github.com/pharo-vcs/iceberg/pull/1680 - Remove unused variable #1695 https://github.com/pharo-vcs/iceberg/pull/1695 - Fix for adding a SSH credential from UI raises an Error #1638 https://github.com/pharo-vcs/iceberg/pull/1638 - Use ED25519 keys as default instead of RSA to improve security and follow new GitHub standards #1649 https://github.com/pharo-vcs/iceberg/pull/1649 - [fix] prevent Iceberg window to crash when the registry is empty #1670 https://github.com/pharo-vcs/iceberg/pull/1670 - Fix for issue #11969 in pharo repository: Better description "packages unloaded packages #1672 https://github.com/pharo-vcs/iceberg/pull/1672 #Pharo 12 ## Enhancements - Completion menu: some love on the detail window #13473 https://github.com/pharo-project/pharo/pull/13473 - Use Pharo12 branch of Spec and NewTools #13460 https://github.com/pharo-project/pharo/pull/13460 - Fix random failure of Ombu in windows. #13448 https://github.com/pharo-project/pharo/pull/13448 - Make protocol of super method a priority in MethodClassifier #13426 https://github.com/pharo-project/pharo/pull/13426 - Cut dependency from CommandLine to UIManager #13431 https://github.com/pharo-project/pharo/pull/13431 - Fix typo introduced in merge #13446 https://github.com/pharo-project/pharo/pull/13446 - Added inspector extensions for RPackage #509 https://github.com/pharo-spec/NewTools/pull/509 ## RPackage and SystemOrganizer - Synch bug in RPackage removal #13496 https://github.com/pharo-project/pharo/pull/13496 ## Protocol and Categories - Keep pushing protocols usage #13443 https://github.com/pharo-project/pharo/pull/13443 - Add some tests on classifications of methods #13485 https://github.com/pharo-project/pharo/pull/13485 - Rename #removeMethodTag: into #removeProtocolIfEmpty: #13492 https://github.com/pharo-project/pharo/pull/13492 - Make #renameProtocolNamed:toBe: manage nils #13480 https://github.com/pharo-project/pharo/pull/13480 - Cleaning of #classify:inProtocolNamed: #13454 https://github.com/pharo-project/pharo/pull/13454 - Deprecate comment management of ClassOrganization #13464 https://github.com/pharo-project/pharo/pull/13464 - Remove ClassOrganization>>#silentlyRenameProtocolNamed:toBe: in favor of always announcing the rename #13458 https://github.com/pharo-project/pharo/pull/13458 - Improve ClassOrganization copy #13453 https://github.com/pharo-project/pharo/pull/13453 - Do not use #classComment #1376 https://github.com/pharo-spec/Spec/pull/1376 ## Compiler: Syntax Hightlight - SHRBTextStyler class>>#blueStyleTable distinguish some variables #13501 https://github.com/pharo-project/pharo/pull/13501 - Improve style for parenthesis, comments and syntax error #13491 https://github.com/pharo-project/pharo/pull/13491 - CodeSnippet: industrialize the testing of the styler #13490 https://github.com/pharo-project/pharo/pull/13490 - add SHRBStyleAttributionTest>>#testErrorStyle #13489 https://github.com/pharo-project/pharo/pull/13489 - Faulty code: improve highlight and icons #13486 https://github.com/pharo-project/pharo/pull/13486 - Fix bug in parenthesis highlight #13467 https://github.com/pharo-project/pharo/pull/13467 ## Compiler: AST - AST: starting visiting comments #13421 https://github.com/pharo-project/pharo/pull/13421 - Snippet: test more comments and fix some #13500 https://github.com/pharo-project/pharo/pull/13500 - Add support to deprecate globals #13348 https://github.com/pharo-project/pharo/pull/13348 - Compiler: expose the AST #13487 https://github.com/pharo-project/pharo/pull/13487 ## Compiler - Snippets: rename (and negate) isMethod to isScripting #13499 https://github.com/pharo-project/pharo/pull/13499 - Vocabulary: propose "script" in compiler #13301 https://github.com/pharo-project/pharo/pull/13301 - OpalCompiler: permit clients to use receiver: after context: as (a noop) #13498 https://github.com/pharo-project/pharo/pull/13498 - Introduce annotations #13449 https://github.com/pharo-project/pharo/pull/13449 - Use Compiler not #copyWithTrailerBytes #13488 https://github.com/pharo-project/pharo/pull/13488 - Directly update source pointer without creating an additional compiled method #13484 https://github.com/pharo-project/pharo/pull/13484 - remove-embeddSourceInTrailer #13481 https://github.com/pharo-project/pharo/pull/13481 - Compiler: remove #optionEmbeddSources #13479 https://github.com/pharo-project/pharo/pull/13479 - Compiler: explicit the need of requestor scope #13472 https://github.com/pharo-project/pharo/pull/13472 - Kill VariableNotDeclared #13471 https://github.com/pharo-project/pharo/pull/13471 - Factorize UndeclaredVariableErrors #13470 https://github.com/pharo-project/pharo/pull/13470 - Debug can recompile doit and uninstalled method #13469 https://github.com/pharo-project/pharo/pull/13469 - Cleanup OpalCompiler & CompilationContext #13423 https://github.com/pharo-project/pharo/pull/13423 - Compiler: simplify DoIt #13398 https://github.com/pharo-project/pharo/pull/13398 - faulty code: test runtimeSyntaxError #13422 https://github.com/pharo-project/pharo/pull/13422 - Rubric editors (thus calypso) execute doit actions in faulty mode #13450 https://github.com/pharo-project/pharo/pull/13450 - Debugger: can handle new exceptions UndeclaredVariableRead&UndeclaredVariableWrite #508 https://github.com/pharo-spec/NewTools/pull/508 - StTestDebuggerProvider class>>#compileMissingClassContextBuilder use permitUndeclared: #506 https://github.com/pharo-spec/NewTools/pull/506 - add missing SpCodeScriptingInteractionModel>>#needRequestorScope #1378 https://github.com/pharo-spec/Spec/pull/1378 - Spec2-Code: declare 'playground'-related capabilities as a compiler requestor #1377 https://github.com/pharo-spec/Spec/pull/1377 ## Cleanups - Refactoring BlockClosureTest >> testCannotReturn #13459 https://github.com/pharo-project/pharo/pull/13459 ## Trivial - use {} instead of Array with:with: #13483 https://github.com/pharo-project/pharo/pull/13483 - use nested and expression #13475 https://github.com/pharo-project/pharo/pull/13475 - use and expression instead of ifTrueifFalse #13477 https://github.com/pharo-project/pharo/pull/13477 - use and expression instead of ifTrueifFalse #13463 https://github.com/pharo-project/pharo/pull/13463 - Use {} instead of "Array with:" for some usages #13461 https://github.com/pharo-project/pharo/pull/13461

April 21, 2023

Re: Picking neighbouring elements

by Richard O'Keefe

successor of x in c = the smallest element of c that is larger than x min {y | y in c . y > x} predecessor of x in c = the largest element of c that is smaller than x max {y | y in c . y < x} On Thu, 20 Apr 2023 at 21:08, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Dear Richard, > > thanks for that additional piece. I'll put insert-<left/right> on my list > of possible variants. I think we come back to naming after the initial port > is done and everyone can play with it. Generally, I made the observation to > better be careful with names since it's too easy to alienate other or > trigger wrong assumptions. > > New topic! (quote below) > > Honestly, my knowledge of Haskell is rather limited and rusted. Hence, I > am having difficulties understanding what exactly these operations with a > sequence of elements. Can you give an example or some pseude/smalltalk code > from your use-case and library? > > Kind regards > > > Changing the subject a wee bit, there's an operation family > in my library, and I wonder how it would fit into Transducers? > To avoid bias, here's a specification in Haskell (for lists, > because I haven't had any luck installing Data.Witherable). > > uccessorBy, predecessorBy :: (a -> a -> Ordering) -> a -> [a] -> a > successor, predecessor :: Ord a => a -> [a] -> a > > successor = successorBy compare > > successorBy cmp x = minimumBy cmp . filter (\y -> cmp x y == LT) > > predecessor = predecessorBy compare > > predecessorBy cmp = successorBy (flip cmp) > > The reason these operations exist is to pick neighbouring > elements in SortedCollections and SortedSets. But they make > *sense* for any Enumerable. So there are "generic" > definitions with orderrides for those two classes. > > A filter + a reduce . Traditionally, a #select:thenFold:ifNone: > in order to avoid building an intermediate collection. That much > I see how to do with transducers. But you can't get the desired > override for #successor:[sortBlock:][ifNone:] by overriding > #select:thenFold:ifNone: in SortedCollection or SortedSet. So what > *should* one do? > >

April 21, 2023

Yoshiki Ohshima - Croquet Microverse - 26 April 2023

by Giovanni Corriga

For this month's online presentation, Yoshiki Ohshima will demonstrate the Croquet Microverse ( https://croquet.io/ ), which is a 3D collaborative construction environment. It is an incarnation of Smalltalk-based Croquet but instead implemented in JavaScript. Microverse allows a group of users to collaboratively create new objects in a virtual space, and describe their behaviors in the live programming manner that can be used by professional programmers. The object extension mechanism used in the Microverse is heavily influenced by past class and object extension mechanisms, many of which originated from experimentation and implementation in Smalltalk. Likewise, the architecture of the Microverse application framework draws upon other frameworks such as Morphic and AppKit. Yoshiki will explain the connections between those systems and the Microverse. Yoshiki ( https://tinlizzie.org/ohshima/ ) joined Walt Disney Imagineering R&D in 2000 as an intern while attending the graduate school of Tokyo Institute of Technology, and helped develop prototypes of Disney's theme park attractions. He also has been involved in Alan Kay's research group, and participated in the research and development effort of education programming environment Squeak Etoys and later took the leading role. Yoshiki has worked at the Viewpoints Research Institute, SAP Labs CDG, and Y Combinator Research, all of which Dr. Kay founded or helped found. He was awarded his PhD. for designing and implementing a massively parallel particle programming system from Tokyo Institute of Technology. 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/292570084/ ) to receive the meeting details.

April 20, 2023

Re: Picking neighbouring elements

by Steffen MÃ¤rcker

Dear Richard, thanks for that additional piece. I'll put insert-<left/right> on my list of possible variants. I think we come back to naming after the initial port is done and everyone can play with it. Generally, I made the observation to better be careful with names since it's too easy to alienate other or trigger wrong assumptions. New topic! (quote below) Honestly, my knowledge of Haskell is rather limited and rusted. Hence, I am having difficulties understanding what exactly these operations with a sequence of elements. Can you give an example or some pseude/smalltalk code from your use-case and library? Kind regards Changing the subject a wee bit, there's an operation family in my library, and I wonder how it would fit into Transducers? To avoid bias, here's a specification in Haskell (for lists, because I haven't had any luck installing Data.Witherable). uccessorBy, predecessorBy :: (a -> a -> Ordering) -> a -> [a] -> a successor, predecessor :: Ord a => a -> [a] -> a successor = successorBy compare successorBy cmp x = minimumBy cmp . filter (\y -> cmp x y == LT) predecessor = predecessorBy compare predecessorBy cmp = successorBy (flip cmp) The reason these operations exist is to pick neighbouring elements in SortedCollections and SortedSets. But they make *sense* for any Enumerable. So there are "generic" definitions with orderrides for those two classes. A filter + a reduce . Traditionally, a #select:thenFold:ifNone: in order to avoid building an intermediate collection. That much I see how to do with transducers. But you can't get the desired override for #successor:[sortBlock:][ifNone:] by overriding #select:thenFold:ifNone: in SortedCollection or SortedSet. So what *should* one do?

April 20, 2023

Re: Collection>>reduce name clash with transducers

by Richard O'Keefe

I've always called the block in #inject:into: the *combining* function. Perhaps the reason I don't think of it as a "reducing" function is that setOfSets inject: Set new into: [:acc :each | acc union: each] has a block that combines its arguments in a way that makes the result bigger, not smaller. For what it's worth, Backus used "insert": *insert-right* /*f* where /*f*:ã*x*ã = *x* and /*f*:ã*x*1,*x*2,...,*x*nã = *f*:ã*x*1,/*f*:ã*x*2,...,*x*nãã and /*f*:ã ã = *unit f* *insert-left* \*f* where \*f*:ã*x*ã = *x* and \*f*:ã*x*1,*x*2,...,*x*nã = *f*:ã\*f*:ã*x*1,...,*x*n-1ã,*x*nã and \*f*:ã ã = *unit f* --- https://en.wikipedia.org/wiki/FP_(programming_language) Every day spent debating the words is another day the software isn't getting used, so I'm sorry about prolonging this. Some names are just too confusing. Some years ago, I found it useful to add {value:}...{optionalValue:}... to my library for passing arguments that the receiver may choose to ignore. (The methods are exactly as direct as the {value:}... methods, no extra allocations or anything.) About the same time, Pharo independenty added {cull:}... but it was years before I noticec, because "cull" to me means either (a) to slaughter a large proportion of a population of wild or domestic anmals, or (b) to gather information from a large number of sources. (The concept "reap" is lurking somewhere in the background.) I don't know who came up with that name for pass-optional-argument, but it grates so much I can't bring myself to use it and just make do without optional parameters in Pharo. In fact it was this example that was at the back of my mind. Changing the subject a wee bit, there's an operation family in my library, and I wonder how it would fit into Transducers? To avoid bias, here's a specification in Haskell (for lists, because I haven't had any luck installing Data.Witherable). uccessorBy, predecessorBy :: (a -> a -> Ordering) -> a -> [a] -> a successor, predecessor :: Ord a => a -> [a] -> a successor = successorBy compare successorBy cmp x = minimumBy cmp . filter (\y -> cmp x y == LT) predecessor = predecessorBy compare predecessorBy cmp = successorBy (flip cmp) The reason these operations exist is to pick neighbouring elements in SortedCollections and SortedSets. But they make *sense* for any Enumerable. So there are "generic" definitions with orderrides for those two classes. A filter + a reduce . Traditionally, a #select:thenFold:ifNone: in order to avoid building an intermediate collection. That much I see how to do with transducers. But you can't get the desired override for #successor:[sortBlock:][ifNone:] by overriding #select:thenFold:ifNone: in SortedCollection or SortedSet. So what *should* one do?

April 20, 2023

Re: Project and package structure recommendations

by Steffen MÃ¤rcker

Thank you both for your answers. That is certainly helpful. - I just noticed that most (all?) package names in the Pharo image do not contain spaces although it is possible to create such names. Is this discouraged or are there issues to watch out for? - Is there a reference how the name mangling of packages, categories and such works? For instance, it seems if a class def states "MyPackage-Tests" it appears in MyPackage under the category tests. Kind regards, Steffen Noury Bouraqadi schrieb am Mittwoch, 19. April 2023 19:10:13 (+02:00): BTW, Beside this mailing list, there is the Pharo Discord for discussions. Noury On Apr 19 2023, at 7:06 pm, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: Most projects that I'm aware of, follow something like this: - 1 project per git repository - One or more packages for the functional part, separate packages for the tests (because if you only use categories you can't load only the runtime required code and exclude the tests) - If your project has optional parts, and this code is in different packages you can provide in the Baseline "groups" for loading sub-sets of the packages Usually, we use https://github.com/ba-st/GitHub-setup for generating the initial boilerplate of new projects. Regards, Gabriel On Wed, Apr 19, 2023 at 12:55â¯PM Steffen MÃ¤rcker <merkste(a)web.de> wrote: Hi, I'd like to ask for your advice or best practices regarding the package structure of a project. So far I have understood: - Iceberg can store multiple packages (project?) in a git repository - A package (or multiple?) and its dependencies is loaded via a baseline - A package can have flags (= categories?) Suppose, a project has - A core part - One or multipel optional parts, that a user may or may not want to load, too - Tests for the core - Tests for each optional part What's the recommended way to structure this in Pharo? For example, I've seen that some code in Pharo has its tests in the same package but flagged/categorized, other code has a separate package for tests. Also, can a (git) repository have multiple baselines? Sorry, if I am asking the obvious but I did not manage to find guidlines in the documentation yet. It might very well an oversight be myself. Kind regards, Steffen -- Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos unter vivaldi.com herunter

April 20, 2023

Re: Project and package structure recommendations

by Noury Bouraqadi

BTW, Beside this mailing list, there is the Pharo Discord for discussions. Noury On Apr 19 2023, at 7:06 pm, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Most projects that I'm aware of, follow something like this: > > - 1 project per git repository > > - One or more packages for the functional part, separate packages for the tests (because if you only use categories you can't load only the runtime required code and exclude the tests) > - If your project has optional parts, and this code is in different packages you can provide in the Baseline "groups" for loading sub-sets of the packages > > Usually, we use https://github.com/ba-st/GitHub-setup for generating the initial boilerplate of new projects. > > Regards, > Gabriel > > > > On Wed, Apr 19, 2023 at 12:55â¯PM Steffen MÃ¤rcker <merkste(a)web.de (mailto:merkste@web.de)> wrote: > > Hi, > > > > I'd like to ask for your advice or best practices regarding the package > > structure of a project. So far I have understood: > > - Iceberg can store multiple packages (project?) in a git repository > > - A package (or multiple?) and its dependencies is loaded via a baseline > > - A package can have flags (= categories?) > > > > Suppose, a project has > > - A core part > > - One or multipel optional parts, that a user may or may not want to load, > > too > > - Tests for the core > > - Tests for each optional part > > > > What's the recommended way to structure this in Pharo? For example, I've > > seen that some code in Pharo has its tests in the same package but > > flagged/categorized, other code has a separate package for tests. Also, can > > a (git) repository have multiple baselines? > > > > Sorry, if I am asking the obvious but I did not manage to find guidlines in > > the documentation yet. It might very well an oversight be myself. > > > > Kind regards, > > Steffen > >

April 19, 2023

Re: Project and package structure recommendations

by Gabriel Cotelli

Most projects that I'm aware of, follow something like this: - 1 project per git repository - One or more packages for the functional part, separate packages for the tests (because if you only use categories you can't load only the runtime required code and exclude the tests) - If your project has optional parts, and this code is in different packages you can provide in the Baseline "groups" for loading sub-sets of the packages Usually, we use https://github.com/ba-st/GitHub-setup for generating the initial boilerplate of new projects. Regards, Gabriel On Wed, Apr 19, 2023 at 12:55â¯PM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Hi, > > I'd like to ask for your advice or best practices regarding the package > structure of a project. So far I have understood: > - Iceberg can store multiple packages (project?) in a git repository > - A package (or multiple?) and its dependencies is loaded via a baseline > - A package can have flags (= categories?) > > Suppose, a project has > - A core part > - One or multipel optional parts, that a user may or may not want to load, > too > - Tests for the core > - Tests for each optional part > > What's the recommended way to structure this in Pharo? For example, I've > seen that some code in Pharo has its tests in the same package but > flagged/categorized, other code has a separate package for tests. Also, can > a (git) repository have multiple baselines? > > Sorry, if I am asking the obvious but I did not manage to find guidlines in > the documentation yet. It might very well an oversight be myself. > > Kind regards, > Steffen >

April 19, 2023

Project and package structure recommendations

by Steffen MÃ¤rcker

Hi, I'd like to ask for your advice or best practices regarding the package structure of a project. So far I have understood: - Iceberg can store multiple packages (project?) in a git repository - A package (or multiple?) and its dependencies is loaded via a baseline - A package can have flags (= categories?) Suppose, a project has - A core part - One or multipel optional parts, that a user may or may not want to load, too - Tests for the core - Tests for each optional part What's the recommended way to structure this in Pharo? For example, I've seen that some code in Pharo has its tests in the same package but flagged/categorized, other code has a separate package for tests. Also, can a (git) repository have multiple baselines? Sorry, if I am asking the obvious but I did not manage to find guidlines in the documentation yet. It might very well an oversight be myself. Kind regards, Steffen

April 19, 2023