January 2022 - Pharo-users - lists.pharo.org

Re: Cairo rendering - why the difference between Pharo and VisualWorks - Quartz?

by Stewart MacLean

Hi Esteban, Yes, I create Rossal shapes (including a custom PangoLabel) and then open the canvas using Morphic. Interestingly if I use the command line pango-view to render to a file, the results are the same as Pharo. On Sat, Jan 29, 2022 at 9:59 PM Esteban Lorenzano <estebanlm(a)netc.eu> wrote: > Hi, > > Are you rendering your Cairo results inside a Morphic window? > > Esteban > On Jan 29 2022, at 8:42 am, Stewart Maclean <stewart(a)xtra.co.nz> wrote: > > > Hi, > > I am working on a proof of concept reimplementation of an application > developed in VisualWorks using Cairo and Pango. > > When I compare the renderings I see that the VisualWorks has a finer > grained resolution. > > Initially I thought is was to do with my anti aliasing settings, but upon > further investigation I'm wondering if it is because the VisualWorks uses > the Quartz backend. > > Please see the attached for a comparison - Pharo rendering using Cairo and > Pango on the left, VisualWorks using Cairo and Pango on the right. Notice > the almost double the number of "pixels". > > I've tried switching to using the Quartz Athens surface, but nothing gets > displayed. > > I would appreciate it if someone can confirm that my analysis is correct, > and that in order to get the better results I would need to hook up to the > Quartz backend? > > Thanks, > > Stewart > >

Jan. 29, 2022

Re: Cairo rendering - why the difference between Pharo and VisualWorks - Quartz?

by Esteban Lorenzano

Hi, Are you rendering your Cairo results inside a Morphic window? Esteban On Jan 29 2022, at 8:42 am, Stewart Maclean <stewart(a)xtra.co.nz> wrote: > > Hi, > > I am working on a proof of concept reimplementation of an application developed in VisualWorks using Cairo and Pango. > > When I compare the renderings I see that the VisualWorks has a finer grained resolution. > > Initially I thought is was to do with my anti aliasing settings, but upon further investigation I'm wondering if it is because the VisualWorks uses the Quartz backend. > > Please see the attached for a comparison - Pharo rendering using Cairo and Pango on the left, VisualWorks using Cairo and Pango on the right. Notice the almost double the number of "pixels". > > I've tried switching to using the Quartz Athens surface, but nothing gets displayed. > > I would appreciate it if someone can confirm that my analysis is correct, and that in order to get the better results I would need to hook up to the Quartz backend? > > Thanks, > > Stewart

Jan. 29, 2022

Cairo rendering - why the difference between Pharo and VisualWorks - Quartz?

by Stewart Maclean

Hi, I am working on a proof of concept reimplementation of an application developed in VisualWorks using Cairo and Pango. When I compare the renderings I see that the VisualWorks has a finer grained resolution. Initially I thought is was to do with my anti aliasing settings, but upon further investigation I'm wondering if it is because the VisualWorks uses the Quartz backend. Please see the attached for a comparison - Pharo rendering using Cairo and Pango on the left, VisualWorks using Cairo and Pango on the right. Notice the almost double the number of "pixels". I've tried switching to using the Quartz Athens surface, but nothing gets displayed. I would appreciate it if someone can confirm that my analysis is correct, and that in order to get the better results I would need to hook up to the Quartz backend? Thanks, Stewart

Jan. 29, 2022

Re: Too many parenthesis - a matter of syntax

by Vitor Medina Cruz

I think that's OK when you can choose when to use parentheses. If you think it would improve readability it is ok to use it, the problem is to be forced to use it even when you think it decreases readability, what I believe to be the case in discussion. On Thu, Jan 27, 2022 at 3:24 PM Russ Whaley <whaley.russ(a)gmail.com> wrote: > What I like about parentheses (and I hate parentheses) is that it allows > me to view/describe the intent of the code. When parens are not used, it is > up to me (perhaps years later) to determine whether the original developer > (sometimes me) understood (or not) the actual 'order of processing'. > Parens - or another vehicle - should help me understand the intent (as > would detailed comments) - so I can devise tests (oh yeah, are those > available, too?) for the intent - even if it is just me in the debugger. > > So, I'm for whatever helps me understand the intent of the code - even if > there is some slick way to nest everything. I generally prefer breaking > nested processes down into multiple steps. Benchmarking rarely shows > significant performance differences, for me. > > (and I've used parentheses 7 times in this one email!) :-) > > Russ > > On Wed, Jan 26, 2022 at 4:20 AM Kasper Osterbye <kasper.osterbye(a)gmail.com> > wrote: > >> Cheers all >> >> I have noticed that I often ends up with quite a number of nested >> expressions, for example: >> >> (((json at: 'tree') >> select: [ :e | (e at: 'type') = âblob' ]) >> collect: [:e | Path from: (e at: 'path')]) >> select: [ :p | p segments last >> in: [ :name | (name endsWith: '.md') | >> (name endsWith: '.mic') ] ] >> >> What kind of proposals (if any) have been for a different syntax which >> could give a more streamlined syntax? >> >> My own thinking has been around an alternative to the cascade semicolon. >> What symbol to use does not matter for me, but something like >> json at: âtree' Âº >> select: [ :e | ((e at: 'type') = 'blobâ)]Âº >> collect: [:e | Path from: (e at: 'pathâ)]Âº >> select: [ :p | p segments last >> in: [ :name | (name endsWith: '.md') | (name endsWith: >> '.mic') ] ] >> >> Basically, a send the right hand expression to the result of the left >> hand expression. >> >> Has anyone ever tried this, or is it just one of the many small >> annoyances best left alone? >> >> Best, >> >> Kasper > > > > -- > Russ Whaley > whaley.russ(a)gmail.com >

Jan. 28, 2022

Re: Too many parenthesis - a matter of syntax

by Russ Whaley

What I like about parentheses (and I hate parentheses) is that it allows me to view/describe the intent of the code. When parens are not used, it is up to me (perhaps years later) to determine whether the original developer (sometimes me) understood (or not) the actual 'order of processing'. Parens - or another vehicle - should help me understand the intent (as would detailed comments) - so I can devise tests (oh yeah, are those available, too?) for the intent - even if it is just me in the debugger. So, I'm for whatever helps me understand the intent of the code - even if there is some slick way to nest everything. I generally prefer breaking nested processes down into multiple steps. Benchmarking rarely shows significant performance differences, for me. (and I've used parentheses 7 times in this one email!) :-) Russ On Wed, Jan 26, 2022 at 4:20 AM Kasper Osterbye <kasper.osterbye(a)gmail.com> wrote: > Cheers all > > I have noticed that I often ends up with quite a number of nested > expressions, for example: > > (((json at: 'tree') > select: [ :e | (e at: 'type') = âblob' ]) > collect: [:e | Path from: (e at: 'path')]) > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | > (name endsWith: '.mic') ] ] > > What kind of proposals (if any) have been for a different syntax which > could give a more streamlined syntax? > > My own thinking has been around an alternative to the cascade semicolon. > What symbol to use does not matter for me, but something like > json at: âtree' Âº > select: [ :e | ((e at: 'type') = 'blobâ)]Âº > collect: [:e | Path from: (e at: 'pathâ)]Âº > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: > '.mic') ] ] > > Basically, a send the right hand expression to the result of the left hand > expression. > > Has anyone ever tried this, or is it just one of the many small annoyances > best left alone? > > Best, > > Kasper -- Russ Whaley whaley.russ(a)gmail.com

Jan. 27, 2022

Re: Too many parenthesis - a matter of syntax

by Vitor Medina Cruz

I understand the point of not adding more syntax and I agree with it, but I think this is such big missing feature in Pharo and that it could be provided by default in the image as an API instead of a syntax sugar. https://github.com/dvmason/Pharo-Functional has both approaches â syntax and API â and I really like the `chain` strategy â I had implemented one of my own some years ago based on a suggestion made here on this list. So the original example code would be like this: json *chain* at: âtree'; select: [ :e | ((e at: 'type') = 'blobâ)]; collect: [:e | Path from: (e at: 'pathâ)]; select: [ :p | p segments last in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] The chain stores the last returned object to be used as the receiver of the next message send. You can do it using a DNU, but maybe there is a more optimized way of doing it, and also using DNU do not work with messages present on the chain base class (Object), maybe tehre is a way to circumvent that also. Regards, Vitor On Wed, Jan 26, 2022 at 11:33 AM Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > On Wed, Jan 26, 2022 at 4:40 AM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Hi Kaspar, >> >> I found the initial example actually reasonable readable. >> >> However, I would simplify it as follows: >> >> (json at: #tree) >> select: [ :each | >> ((each at: #type) = #blob) >> and: [ #(md mic) includes: (Path from: (each at: #path)) extension >> ] ]. >> >> I would personally not try to extend the Smalltalk syntax. The cost is >> not worth the gain. >> >> Tools could be written to help in dealing with deeply nested structures >> (JSON/XML), they could form their own DSL at a higher level. >> >> For a limited example, NeoJSONObject uses the DNU trick to support unary >> accessors: >> >> json at: #tree >> >> can be written as >> >> json tree >> >> and has a path accessor: >> >> json atPath: #(tree field name) >> >> it also behaves like JavaScript objects in that missing keys are nil. It >> is not that all this is good or better, it is just handy in some cases. >> Your code would then be even simpler (less parenthesis): >> >> json tree select: [ :each | >> (each type = #blob) >> and: [ #(md mic) includes: (Path from: each path) extension ] ]. >> > > That is the kind of expressiveness I was looking for! > > > >> Sven >> >> > On 26 Jan 2022, at 10:19, Kasper Osterbye <kasper.osterbye(a)gmail.com> >> wrote: >> > >> > Cheers all >> > >> > I have noticed that I often ends up with quite a number of nested >> expressions, for example: >> > >> > (((json at: 'tree') >> > select: [ :e | (e at: 'type') = âblob' ]) >> > collect: [:e | Path from: (e at: 'path')]) >> > select: [ :p | p segments last >> > in: [ :name | (name endsWith: '.md') | >> (name endsWith: '.mic') ] ] >> > >> > What kind of proposals (if any) have been for a different syntax which >> could give a more streamlined syntax? >> > >> > My own thinking has been around an alternative to the cascade >> semicolon. What symbol to use does not matter for me, but something like >> > json at: âtree' Âº >> > select: [ :e | ((e at: 'type') = 'blobâ)]Âº >> > collect: [:e | Path from: (e at: 'pathâ)]Âº >> > select: [ :p | p segments last >> > in: [ :name | (name endsWith: '.md') | (name endsWith: >> '.mic') ] ] >> > >> > Basically, a send the right hand expression to the result of the left >> hand expression. >> > >> > Has anyone ever tried this, or is it just one of the many small >> annoyances best left alone? >> > >> > Best, >> > >> > Kasper >> >

Jan. 26, 2022

Re: isAbstract in WAIPSessionTrackingStrategy meet my new hobby horse

by Marcus Denker

Y > On 26 Jan 2022, at 15:55, gettimothy via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > WAIPSessionTrackingStrategy > isAbstract > ^true > has just ran into my new hobby horse. > > I am reading through every class in Seaside to document it and I had an 'aha!' moment > > on the design of Abstract super classes like WABrush: > > WABrush > isAbstract > > ^ self == WABrush > > > The simplicity is genius because no subclass of WABrush has to implement isAbstract, whereas in WAIPSessionTrackingStrategy, concrete subclasses (of which there currently are none) will have to. > Exactly, that is the idea of the pattern. On the downside it is not easy to understand (you have to think about it the first time you see it) and it feels (to me) âuglyâ. Maybe because it encodes meta-data of the class, which should be declarative, as a method? Instead of improving the meta-model (and thus our understanding) of what a class is? But it is the best we have now. There is even a âmake class abstractâ refactoring method in Pharo10, and we adapted the Code Critique to not complain about the direct class reference for these methods. > In defense of the WAIPSessionTrackingStrategy implementation, the comment reads: > I track sessions using the remote address of a client. > Usually you don't want to use this because it causes troubles when multiple users share the same IP (eg. several users from the same company). > > That's why I'm marked as abstract. > > There are some special cases like crawlers where it can work though. > > So, apparently, the author is anticipating somebody someday using it. > Maybe you can add an issue to the seaside issue tracker? Marcus

Jan. 26, 2022

isAbstract in WAIPSessionTrackingStrategy meet my new hobby horse

by gettimothy

WAIPSessionTrackingStrategyÂ > isAbstract Â Â ^true has just ran into my new hobby horse. I am reading through every class in Seaside to document it and I had an 'aha!' moment on the design of Abstract super classes like WABrush: WABrush > isAbstract Â Â Â Â Â Â ^ self == WABrush The simplicity is genius because no subclass of WABrush has to implement isAbstract, whereas in WAIPSessionTrackingStrategy, concrete subclasses (of which there currently are none) will have to. In defense of the WAIPSessionTrackingStrategy implementation, the comment reads: I track sessions using the remote address of a client. Usually you don't want to use this because it causes troubles when multiple users share the same IP (eg. several users from the same company). That's why I'm marked as abstract. There are some special cases like crawlers where it can work though. Â So, apparently, the author is anticipating somebody someday using it.

Jan. 26, 2022

Re: Too many parenthesis - a matter of syntax

by Richard Sargent

On Wed, Jan 26, 2022 at 4:40 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Kaspar, > > I found the initial example actually reasonable readable. > > However, I would simplify it as follows: > > (json at: #tree) > select: [ :each | > ((each at: #type) = #blob) > and: [ #(md mic) includes: (Path from: (each at: #path)) extension ] > ]. > > I would personally not try to extend the Smalltalk syntax. The cost is not > worth the gain. > > Tools could be written to help in dealing with deeply nested structures > (JSON/XML), they could form their own DSL at a higher level. > > For a limited example, NeoJSONObject uses the DNU trick to support unary > accessors: > > json at: #tree > > can be written as > > json tree > > and has a path accessor: > > json atPath: #(tree field name) > > it also behaves like JavaScript objects in that missing keys are nil. It > is not that all this is good or better, it is just handy in some cases. > Your code would then be even simpler (less parenthesis): > > json tree select: [ :each | > (each type = #blob) > and: [ #(md mic) includes: (Path from: each path) extension ] ]. > That is the kind of expressiveness I was looking for! > Sven > > > On 26 Jan 2022, at 10:19, Kasper Osterbye <kasper.osterbye(a)gmail.com> > wrote: > > > > Cheers all > > > > I have noticed that I often ends up with quite a number of nested > expressions, for example: > > > > (((json at: 'tree') > > select: [ :e | (e at: 'type') = âblob' ]) > > collect: [:e | Path from: (e at: 'path')]) > > select: [ :p | p segments last > > in: [ :name | (name endsWith: '.md') | > (name endsWith: '.mic') ] ] > > > > What kind of proposals (if any) have been for a different syntax which > could give a more streamlined syntax? > > > > My own thinking has been around an alternative to the cascade semicolon. > What symbol to use does not matter for me, but something like > > json at: âtree' Âº > > select: [ :e | ((e at: 'type') = 'blobâ)]Âº > > collect: [:e | Path from: (e at: 'pathâ)]Âº > > select: [ :p | p segments last > > in: [ :name | (name endsWith: '.md') | (name endsWith: > '.mic') ] ] > > > > Basically, a send the right hand expression to the result of the left > hand expression. > > > > Has anyone ever tried this, or is it just one of the many small > annoyances best left alone? > > > > Best, > > > > Kasper >

Jan. 26, 2022

Re: Too many parenthesis - a matter of syntax

by Esteban Maringolo

On Wed, Jan 26, 2022 at 10:58 AM gettimothy via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > I realize this is just a preference, but the denseness forces me to think in Objects and composition rather than process. I never thought of it this way, but I fully agree with it. Thanks for putting this in words. Maybe what we need is better highlighting of the current "scope" where the cursor is. Navigating in and out of the parenthesis is not trivial, and it feels like hunting sometimes. With Futures it would be convenient to be able to link different #then: and such, but what you might need is a "chained" object that does all that for you. I always think of ways to improve the current syntax, but in the end it seems like anything else feels unnatural, and the net result is not positive. So... more objects, less syntax... and better tooling. Regards, Esteban A. Maringolo

Jan. 26, 2022

Re: Too many parenthesis - a matter of syntax

by gettimothy

Also...learning to think in Smalltalk has taught me to understand Lisp. As an Emacs guy, that is a good thing (:

Jan. 26, 2022

Re: Too many parenthesis - a matter of syntax

by gettimothy

I like the parenthesis. The thinking process is very much like "thinking in Sets" when building a complex SQLÂ statement. The result is a lot of power in an dense, elegant expression. If, as is often the case with me, I find a nested expression as below too complex, it is very easy to decompose it. I realize this is just a preference, but the denseness forces me to think in Objects and composition rather than process. just my .02 cents. cheers. ---- On Wed, 26 Jan 2022 04:19:39 -0500 Kasper Osterbye <kasper.osterbye(a)gmail.com> wrote ---- Cheers all I have noticed that I often ends up with quite a number of nested expressions, for example: (((json at: 'tree') Â Â Â Â select: [ :e | (e at: 'type') = âblob' ]) Â Â Â Â Â Â Â Â collect: [:e | Path from: (e at: 'path')]) Â Â Â Â Â Â Â Â Â Â Â Â select: [ :p | p segments last Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] What kind of proposals (if any) have been for a different syntax which could give a more streamlined syntax? My own thinking has been around an alternative to the cascade semicolon. What symbol to use does not matter for me, but something like json at: âtree' Âº Â Â Â Â select: [ :e | ((e at: 'type') = 'blobâ)]Âº Â Â Â Â collect: [:e | Path from: (e at: 'pathâ)]Âº Â Â Â Â select: [ :p | p segments last Â Â Â Â Â Â Â Â in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] Basically, a send the right hand expression to the result of the left hand expression. Has anyone ever tried this, or is it just one of the many small annoyances best left alone? Best, Kasper

Jan. 26, 2022

Re: Too many parenthesis - a matter of syntax

by Sven Van Caekenberghe

Hi Kaspar, I found the initial example actually reasonable readable. However, I would simplify it as follows: (json at: #tree) select: [ :each | ((each at: #type) = #blob) and: [ #(md mic) includes: (Path from: (each at: #path)) extension ] ]. I would personally not try to extend the Smalltalk syntax. The cost is not worth the gain. Tools could be written to help in dealing with deeply nested structures (JSON/XML), they could form their own DSL at a higher level. For a limited example, NeoJSONObject uses the DNU trick to support unary accessors: json at: #tree can be written as json tree and has a path accessor: json atPath: #(tree field name) it also behaves like JavaScript objects in that missing keys are nil. It is not that all this is good or better, it is just handy in some cases. Your code would then be even simpler (less parenthesis): json tree select: [ :each | (each type = #blob) and: [ #(md mic) includes: (Path from: each path) extension ] ]. Sven > On 26 Jan 2022, at 10:19, Kasper Osterbye <kasper.osterbye(a)gmail.com> wrote: > > Cheers all > > I have noticed that I often ends up with quite a number of nested expressions, for example: > > (((json at: 'tree') > select: [ :e | (e at: 'type') = âblob' ]) > collect: [:e | Path from: (e at: 'path')]) > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] > > What kind of proposals (if any) have been for a different syntax which could give a more streamlined syntax? > > My own thinking has been around an alternative to the cascade semicolon. What symbol to use does not matter for me, but something like > json at: âtree' Âº > select: [ :e | ((e at: 'type') = 'blobâ)]Âº > collect: [:e | Path from: (e at: 'pathâ)]Âº > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] > > Basically, a send the right hand expression to the result of the left hand expression. > > Has anyone ever tried this, or is it just one of the many small annoyances best left alone? > > Best, > > Kasper

Jan. 26, 2022

Re: Too many parenthesis - a matter of syntax

by jtuchel＠objektfabrik.de

Kasper, I wouldn't say your suggestion looks any more readable than the many parentheses of the original expression. The whole operation is complex enough to be hard to understand. So I agree with both Richard and Sebastian - you should either make the steps readable by giving the intermediate results good names or factor the whole operation out into some object and good method name (which would be hard to read in itself without the temp vars, so you should pobably combine both suggestions). My opinion may be irrelevant, as I don't hold a "real" CS degree. I look at this from the perspective of the poor guy who has to debug this in three years rather than from an angle of elegance or conciseness. I guess even something like the .then() - syntax from Javascrpt wouldn't make this any more readable. And whatever symbol you'd chose it wouldn't communicate what's happening... Joachim Am 26.01.22 um 10:19 schrieb Kasper Osterbye: > Cheers all > > I have noticed that I often ends up with quite a number of nested expressions, for example: > > (((json at: 'tree') > select: [ :e | (e at: 'type') = âblob' ]) > collect: [:e | Path from: (e at: 'path')]) > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] > > What kind of proposals (if any) have been for a different syntax which could give a more streamlined syntax? > > My own thinking has been around an alternative to the cascade semicolon. What symbol to use does not matter for me, but something like > json at: âtree' Âº > select: [ :e | ((e at: 'type') = 'blobâ)]Âº > collect: [:e | Path from: (e at: 'pathâ)]Âº > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] > > Basically, a send the right hand expression to the result of the left hand expression. > > Has anyone ever tried this, or is it just one of the many small annoyances best left alone? > > Best, > > Kasper -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Jan. 26, 2022

Re: Too many parenthesis - a matter of syntax

by Marcus Denker

But does this help? Now the simple nested query is some serious code. I, too, like the idea that a query expression like the one shown should have a nice syntaxâ¦ without the need for variables. I always thought that the nice collection API would be nicer if we could write them without parenthesis... How to do that right is of course not easy. There are experiments around, for example https://github.com/dvmason/Pharo-Functional > On 26 Jan 2022, at 11:11, Sebastian Jordan Montano <sebastian.jordan(a)inria.fr> wrote: > > I agree that the expression is unreadable. What I would initially do is to extract it into temporary variables. > Like: > > tree := json at: 'tree'. > blobs := tree select: [ :each | (each at: 'type') = 'blob' ]. > paths := blobs collect: [ :each | Path from: (each at: 'path')]). > ... > > After you can see if you can extract the logic into different classes or other methods. > > Sebastian > > De: "Richard Sargent" <richard.sargent(a)gemtalksystems.com> > Ã: "pharo-users" <pharo-users(a)lists.pharo.org> > EnvoyÃ©: Mercredi 26 Janvier 2022 09:55:30 > Objet: [Pharo-users] Re: Too many parenthesis - a matter of syntax > On Wed, Jan 26, 2022, 01:20 Kasper Osterbye <kasper.osterbye(a)gmail.com <mailto:kasper.osterbye@gmail.com>> wrote: > Cheers all > > I have noticed that I often ends up with quite a number of nested expressions, for example: > > (((json at: 'tree') > select: [ :e | (e at: 'type') = âblob' ]) > collect: [:e | Path from: (e at: 'path')]) > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] > > What kind of proposals (if any) have been for a different syntax which could give a more streamlined syntax? > > What's written is basically unreadable and syntax changes won't help. > > Try taking out the constants and describing their relationship with a new message or a couple of messages. > > Without trying to understand it, it looks like you have some navigation followed by some filtering / suffix selection. > > Try to develop an expression that articulates the meaning of what you're doing. > > > My own thinking has been around an alternative to the cascade semicolon. What symbol to use does not matter for me, but something like > json at: âtree' Âº > select: [ :e | ((e at: 'type') = 'blobâ)]Âº > collect: [:e | Path from: (e at: 'pathâ)]Âº > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] > > Basically, a send the right hand expression to the result of the left hand expression. > > Has anyone ever tried this, or is it just one of the many small annoyances best left alone? > > Best, > > Kasper >

Jan. 26, 2022

Re: Too many parenthesis - a matter of syntax

by Sebastian Jordan Montano

I agree that the expression is unreadable. What I would initially do is to extract it into temporary variables. Like: tree := json at: 'tree'. blobs := tree select: [ :each | (each at: 'type') = 'blob' ]. paths := blobs collect: [ :each | Path from: (each at: 'path')]). ... After you can see if you can extract the logic into different classes or other methods. Sebastian > De: "Richard Sargent" <richard.sargent(a)gemtalksystems.com> > Ã: "pharo-users" <pharo-users(a)lists.pharo.org> > EnvoyÃ©: Mercredi 26 Janvier 2022 09:55:30 > Objet: [Pharo-users] Re: Too many parenthesis - a matter of syntax > On Wed, Jan 26, 2022, 01:20 Kasper Osterbye < [ mailto:kasper.osterbye@gmail.com > | kasper.osterbye(a)gmail.com ] > wrote: >> Cheers all >> I have noticed that I often ends up with quite a number of nested expressions, >> for example: >> (((json at: 'tree') >> select: [ :e | (e at: 'type') = âblob' ]) >> collect: [:e | Path from: (e at: 'path')]) >> select: [ :p | p segments last >> in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] >> What kind of proposals (if any) have been for a different syntax which could >> give a more streamlined syntax? > What's written is basically unreadable and syntax changes won't help. > Try taking out the constants and describing their relationship with a new > message or a couple of messages. > Without trying to understand it, it looks like you have some navigation followed > by some filtering / suffix selection. > Try to develop an expression that articulates the meaning of what you're doing. >> My own thinking has been around an alternative to the cascade semicolon. What >> symbol to use does not matter for me, but something like >> json at: âtree' Âº >> select: [ :e | ((e at: 'type') = 'blobâ)]Âº >> collect: [:e | Path from: (e at: 'pathâ)]Âº >> select: [ :p | p segments last >> in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] >> Basically, a send the right hand expression to the result of the left hand >> expression. >> Has anyone ever tried this, or is it just one of the many small annoyances best >> left alone? >> Best, >> Kasper

Jan. 26, 2022

Re: Too many parenthesis - a matter of syntax

by Richard Sargent

On Wed, Jan 26, 2022, 01:20 Kasper Osterbye <kasper.osterbye(a)gmail.com> wrote: > Cheers all > > I have noticed that I often ends up with quite a number of nested > expressions, for example: > > (((json at: 'tree') > select: [ :e | (e at: 'type') = âblob' ]) > collect: [:e | Path from: (e at: 'path')]) > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | > (name endsWith: '.mic') ] ] > > What kind of proposals (if any) have been for a different syntax which > could give a more streamlined syntax? > What's written is basically unreadable and syntax changes won't help. Try taking out the constants and describing their relationship with a new message or a couple of messages. Without trying to understand it, it looks like you have some navigation followed by some filtering / suffix selection. Try to develop an expression that articulates the meaning of what you're doing. > My own thinking has been around an alternative to the cascade semicolon. > What symbol to use does not matter for me, but something like > json at: âtree' Âº > select: [ :e | ((e at: 'type') = 'blobâ)]Âº > collect: [:e | Path from: (e at: 'pathâ)]Âº > select: [ :p | p segments last > in: [ :name | (name endsWith: '.md') | (name endsWith: > '.mic') ] ] > > Basically, a send the right hand expression to the result of the left hand > expression. > > Has anyone ever tried this, or is it just one of the many small annoyances > best left alone? > > Best, > > Kasper

Jan. 26, 2022

Too many parenthesis - a matter of syntax

by Kasper Osterbye

Cheers all I have noticed that I often ends up with quite a number of nested expressions, for example: (((json at: 'tree') select: [ :e | (e at: 'type') = âblob' ]) collect: [:e | Path from: (e at: 'path')]) select: [ :p | p segments last in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] What kind of proposals (if any) have been for a different syntax which could give a more streamlined syntax? My own thinking has been around an alternative to the cascade semicolon. What symbol to use does not matter for me, but something like json at: âtree' Âº select: [ :e | ((e at: 'type') = 'blobâ)]Âº collect: [:e | Path from: (e at: 'pathâ)]Âº select: [ :p | p segments last in: [ :name | (name endsWith: '.md') | (name endsWith: '.mic') ] ] Basically, a send the right hand expression to the result of the left hand expression. Has anyone ever tried this, or is it just one of the many small annoyances best left alone? Best, Kasper

Jan. 26, 2022

Re: UK Smalltalk User Group Meeting - Wednesday, January 26th

by James Foster

You are right that it is at 11:00 AM PST. I clicked on the link and didnât recognize that the web site set the time to my local timezone. Very nice! > On Jan 18, 2022, at 9:56 AM, Martin McClure <martin.mcclure(a)gemtalksystems.com> wrote: > > I believe this will be recorded. > And for someone it will be at 3AM. > In your time zone, James, I believe it will be at 11AM. > > Regards, > -Martin > > On 1/18/22 07:55, James Foster wrote: >> Will this be recorded for later viewing (for those of us who would prefer to be asleep at 3am)? >> >> James >> >>> On Jan 17, 2022, at 2:30 PM, Giovanni Corriga <giovanni(a)corriga.net <mailto:giovanni@corriga.net>> wrote: >>> >>> For our January meeting, we'll be hosting GemTalk's Martin McClure who will talk about a new Smalltalk IDE - Sparkle. >>> >>> If you're setting out to develop a Smalltalk IDE from scratch, what design decisions do you make? You'd love to "fix" the things that have long annoyed you in existing IDEs, but new designs risk creating their own novel annoyances. >>> The Sparkle project-in-progress is creating a new and not entirely conventional development environment for GemStone Smalltalk. Come see factors that have influenced its design, get a demo of the current state of the tools, learn about the project's next steps, and share *your* IDE annoyances. >>> >>> Martin heard about Smalltalk in 1975, *finally* got his hands on a running Smalltalk system ten years later, and hasn't let go since. In his 25 years on the GemStone team, Martin has worked on many aspects - some VM internals, some user interface design, but mostly all the things that go in between. In his rare spare time, he works on Mist, a Smalltalk variant with improved modularity and no virtual machine. When not dodging Covid, he does a lot of contra and country dancing. >>> >>> 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/282299228/ <https://www.meetup.com/UKSTUG/events/282299228/> ) to receive the meeting details. Donât forget to bring your laptop and drinks! >>> >> >

Jan. 18, 2022

Re: UK Smalltalk User Group Meeting - Wednesday, January 26th

by Bruce O'Neel

Hi, Past recordings have appeared here reasonably quickly after the event. UK Smalltalk User Group (vimeo.com) [https://vimeo.com/ukstug] cheers bruce On 2022-01-18T16:55:37.000+01:00, James Foster <smalltalk(a)jgfoster.net> wrote: >Â WillÂ thisÂ beÂ recordedÂ forÂ laterÂ viewingÂ (forÂ thoseÂ ofÂ usÂ whoÂ would >Â preferÂ toÂ beÂ asleepÂ atÂ 3am)? >Â >Â James >Â >>Â Â OnÂ JanÂ 17,Â 2022,Â atÂ 2:30Â PM,Â GiovanniÂ Corriga >>Â Â <giovanni(a)corriga.net>Â wrote: >>Â Â >>Â Â ForÂ ourÂ JanuaryÂ meeting,Â we'llÂ beÂ hostingÂ GemTalk'sÂ MartinÂ McClure >>Â Â whoÂ willÂ talkÂ aboutÂ aÂ newÂ SmalltalkÂ IDEÂ -Â Sparkle. >>Â Â >>Â Â IfÂ you'reÂ settingÂ outÂ toÂ developÂ aÂ SmalltalkÂ IDEÂ fromÂ scratch, >>Â Â whatÂ designÂ decisionsÂ doÂ youÂ make?Â You'dÂ loveÂ toÂ "fix"Â theÂ things >>Â Â thatÂ haveÂ longÂ annoyedÂ youÂ inÂ existingÂ IDEs,Â butÂ newÂ designsÂ risk >>Â Â creatingÂ theirÂ ownÂ novelÂ annoyances. >>Â Â TheÂ SparkleÂ project-in-progressÂ isÂ creatingÂ aÂ newÂ andÂ notÂ entirely >>Â Â conventionalÂ developmentÂ environmentÂ forÂ GemStoneÂ Smalltalk.Â Come >>Â Â seeÂ factorsÂ thatÂ haveÂ influencedÂ itsÂ design,Â getÂ aÂ demoÂ ofÂ the >>Â Â currentÂ stateÂ ofÂ theÂ tools,Â learnÂ aboutÂ theÂ project'sÂ nextÂ steps, >>Â Â andÂ shareÂ *your*Â IDEÂ annoyances. >>Â Â >>Â Â MartinÂ heardÂ aboutÂ SmalltalkÂ inÂ 1975,Â *finally*Â gotÂ hisÂ handsÂ onÂ a >>Â Â runningÂ SmalltalkÂ systemÂ tenÂ yearsÂ later,Â andÂ hasn'tÂ letÂ goÂ since. >>Â Â InÂ hisÂ 25Â yearsÂ onÂ theÂ GemStoneÂ team,Â MartinÂ hasÂ workedÂ onÂ many >>Â Â aspectsÂ -Â someÂ VMÂ internals,Â someÂ userÂ interfaceÂ design,Â but >>Â Â mostlyÂ allÂ theÂ thingsÂ thatÂ goÂ inÂ between.Â InÂ hisÂ rareÂ spareÂ time, >>Â Â heÂ worksÂ onÂ Mist,Â aÂ SmalltalkÂ variantÂ withÂ improvedÂ modularityÂ and >>Â Â noÂ virtualÂ machine.Â WhenÂ notÂ dodgingÂ Covid,Â heÂ doesÂ aÂ lotÂ of >>Â Â contraÂ andÂ countryÂ dancing. >>Â Â >>Â Â 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/282299228/Â )Â toÂ receive >>Â Â theÂ meetingÂ details.Â DonâtÂ forgetÂ toÂ bringÂ yourÂ laptopÂ and >>Â Â drinks!

Jan. 18, 2022

Re: UK Smalltalk User Group Meeting - Wednesday, January 26th

by James Foster

Will this be recorded for later viewing (for those of us who would prefer to be asleep at 3am)? James > On Jan 17, 2022, at 2:30 PM, Giovanni Corriga <giovanni(a)corriga.net> wrote: > > For our January meeting, we'll be hosting GemTalk's Martin McClure who will talk about a new Smalltalk IDE - Sparkle. > > If you're setting out to develop a Smalltalk IDE from scratch, what design decisions do you make? You'd love to "fix" the things that have long annoyed you in existing IDEs, but new designs risk creating their own novel annoyances. > The Sparkle project-in-progress is creating a new and not entirely conventional development environment for GemStone Smalltalk. Come see factors that have influenced its design, get a demo of the current state of the tools, learn about the project's next steps, and share *your* IDE annoyances. > > Martin heard about Smalltalk in 1975, *finally* got his hands on a running Smalltalk system ten years later, and hasn't let go since. In his 25 years on the GemStone team, Martin has worked on many aspects - some VM internals, some user interface design, but mostly all the things that go in between. In his rare spare time, he works on Mist, a Smalltalk variant with improved modularity and no virtual machine. When not dodging Covid, he does a lot of contra and country dancing. > > 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/282299228/ <https://www.meetup.com/UKSTUG/events/282299228/> ) to receive the meeting details. Donât forget to bring your laptop and drinks! >

Jan. 18, 2022

UK Smalltalk User Group Meeting - Wednesday, January 26th

by Giovanni Corriga

For our January meeting, we'll be hosting GemTalk's Martin McClure who will talk about a new Smalltalk IDE - Sparkle. If you're setting out to develop a Smalltalk IDE from scratch, what design decisions do you make? You'd love to "fix" the things that have long annoyed you in existing IDEs, but new designs risk creating their own novel annoyances. The Sparkle project-in-progress is creating a new and not entirely conventional development environment for GemStone Smalltalk. Come see factors that have influenced its design, get a demo of the current state of the tools, learn about the project's next steps, and share *your* IDE annoyances. Martin heard about Smalltalk in 1975, *finally* got his hands on a running Smalltalk system ten years later, and hasn't let go since. In his 25 years on the GemStone team, Martin has worked on many aspects - some VM internals, some user interface design, but mostly all the things that go in between. In his rare spare time, he works on Mist, a Smalltalk variant with improved modularity and no virtual machine. When not dodging Covid, he does a lot of contra and country dancing. 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/282299228/ ) to receive the meeting details. Donât forget to bring your laptop and drinks!

Jan. 17, 2022

Re: Ubuntu update ... great!

by Esteban Lorenzano

we already have it since months ;) On Jan 15 2022, at 11:22 am, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > We are going to have apt get????? > > On Sat, 15 Jan 2022, 11:05 Norbert Hartl, <norbert(a)hartl.name (mailto:norbert@hartl.name)> wrote: > > Just got an email this morning containing: > > > > The following packages are currently pending an upgrade: > > linux-firmware 1.187.25 > > pharo9 9.0.11-0 > > > > > > This feels great and is highly appreciated that we have that now. I hope we keep doing it like this. > > > > Thanks to Pablo and all that participated in that. > > > > Norbert

Jan. 15, 2022

Re: Ubuntu update ... great!

by Santiago Bragagnolo

We are going to have apt get????? On Sat, 15 Jan 2022, 11:05 Norbert Hartl, <norbert(a)hartl.name> wrote: > Just got an email this morning containing: > > > > > *The following packages are currently pending an upgrade: linux-firmware > 1.187.25 pharo9 9.0.11-0* > > This feels great and is highly appreciated that we have that now. I hope > we keep doing it like this. > > Thanks to Pablo and all that participated in that. > > Norbert >

Jan. 15, 2022

Ubuntu update ... great!

by Norbert Hartl

Just got an email this morning containing: The following packages are currently pending an upgrade: linux-firmware 1.187.25 pharo9 9.0.11-0 This feels great and is highly appreciated that we have that now. I hope we keep doing it like this. Thanks to Pablo and all that participated in that. Norbert

Jan. 15, 2022