- Pharo-users - lists.pharo.org

Re: [Pharo-users] Bloc of code in tiers programming language

by Brainstorms

You got it. Thanks, Ben! After success with Lua, now I'm thinking about how to get Pharo inserted into the culture here... Ben Coman wrote > You mean like this... > > In System Browser... > Object subclass: #A > instanceVariableNames: '' > classVariableNames: '' > package: 'AA' > > A >> block > |a| > ^ [ a := (a ifNil: [ 0 ]) + 1 ] > > In Playground... > b := A new block inspect. > { b value. b value. b value . b } "==> an Array( 1 2 3 [ a := (a > ifNil: [ 0 ]) + 1 ] )" > > cheers -ben -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 16, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Ben Coman

On Fri, 17 May 2019 at 01:21, Brainstorms <wild.ideas(a)gmail.com> wrote: > I beg your pardon.. and thank you for being the first to draw my attention > to > the fact that the phrase (a common enough American colloquialism) is > actually a logical fallacy. Until now, it's been strictly idiomatic to me. > > And thank you for your prompt reply. > > Am I safe to assume that blocks in Smalltalk, as with Lua, capture their > locally-scoped variables (referred to in Lua as "non-local variables") for > correct evaluation in other contexts, such as when blocks are passed as > arguments and return values? I.e., cases where the local variables of a > method have gone out of scope and no longer exist, yet are referenced > within > the block at some future time when evaluated. I expect so; I just haven't > seen it described in this detail. > You mean like this... In System Browser... Object subclass: #A instanceVariableNames: '' classVariableNames: '' package: 'AA' A >> block |a| ^ [ a := (a ifNil: [ 0 ]) + 1 ] In Playground... b := A new block inspect. { b value. b value. b value . b } "==> an Array( 1 2 3 [ a := (a ifNil: [ 0 ]) + 1 ] )" cheers -ben

May 16, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Brainstorms

I beg your pardon.. and thank you for being the first to draw my attention to the fact that the phrase (a common enough American colloquialism) is actually a logical fallacy. Until now, it's been strictly idiomatic to me. And thank you for your prompt reply. Am I safe to assume that blocks in Smalltalk, as with Lua, capture their locally-scoped variables (referred to in Lua as "non-local variables") for correct evaluation in other contexts, such as when blocks are passed as arguments and return values? I.e., cases where the local variables of a method have gone out of scope and no longer exist, yet are referenced within the block at some future time when evaluated. I expect so; I just haven't seen it described in this detail. -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 16, 2019

Re: [Pharo-users] TelePharo / Seamless Bitmaps are all 0s

by Denis Kudriashov

Hi Alistair ÑÑ, 15 Ð¼Ð°Ñ 2019 Ð³. Ð² 10:11, Alistair Grant <akgrant0710(a)gmail.com>: > Hi Denis, > > On Wed, 15 May 2019 at 10:16, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > Hi Alistair > > > > I will look when have a time. > > But you can try to write a test for bitmap serialization/materialization > in TostSerializationTests (if I remember correctly the name). > > It will show if bitmap transport requires extra logic. > > If I remove Bitmap>>travelGuide (so that it inherits the default > OrdinaryObjectTravelGuide instead of an empty travel guide) everything > seems to work OK. > > This seems reasonable to me as a Bitmap's format is basically the same > as an Array, which doesn't seem to require any special processing. > Not really. Bitmap is specifically array of integers. So it does not make sense to traverse it as a complex structure considering that all its items are real objects. it could be quite expensive. Bitmap represents an image (form) and I think it is logical to trait it as a whole structure, like bytearray or string. And EmptyObjectTravelGuide marks such kind of objects to be not traversable. So the issue was with missing implementation of Bitmap serialization. TostSerializer requires that any integral object implements couple of "primitive methods". And it was not done for Bitmap. I fixed serializer and released all dependent projects. So try update TelePharo. > > I can add a simple test and submit a PR (in a few days time) if the > change sounds OK to you. > > Thanks, > Alistair > > > > ÑÑ, 15 Ð¼Ð°Ñ 2019 Ð³., 8:49 Alistair Grant <akgrant0710(a)gmail.com>: > >> > >> Hi Denis, > >> > >> If I print: > >> > >> remotePharo evaluate: [ Array withAll: #(42 42 42) ] "==> #(42 42 42)" > >> > >> which is obviously correct, but: > >> > >> remotePharo evaluate: [ Bitmap withAll: #(42 42 42) ] > >> > >> gives me a bitmap with all zeroes (running it locally does the expected > thing). > >> > >> I can see that the bitmap is being created correctly on the server, > >> but by the time it gets back the values have been lost (all converted > >> to 0s). If I change the Bitmap>>seamlessDefaultTransferStrategy for > >> the Bitmap to #defaultByReference I can correctly access the values > >> (just for debugging, by reference isn't practical for the real > >> system). > >> > >> Any hints on where to look? > >> > >> Thanks again, > >> Alistair > >> > >

May 16, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Richard O'Keefe

I do wish people wouldn't say "beg the question" https://grammarist.com/rhetoric/begging-the-question-fallacy/ when they mean "invites" or "raises" the question. Sigh. Yes, Smalltalk is just like Lua here. |f g| "declare f and g as local variables" f := [... g value ...]. "f uses g's current value" g := [... f value ...]. "g uses f's current value" You cannot mix declarations and statements in Smalltalk. Local variables have to be declared before use. On Thu, 16 May 2019 at 11:31, Brainstorms <wild.ideas(a)gmail.com> wrote: > Richard, > > Question from someone still fairly new to Smalltalk: > > To implement the example you gave regarding mutually recursive functions in > Lua, one must write something like this: > > local f, g > > function g () > <do something> > f() > <do something> > end > > function f () > <do something> > g() > <do something> > end > > where the initial declaration of f & g as locals defines an f such that g > will see it (as a local, albeit containing nil) when g is defined. The > following definition of f doesn't require this, of course. And g doesn't > care what f contains -- until execution time. > > Both Lua and Smalltalk implement full lexical closures, so it begs the > question: Do the blocks defined in your example have this same issue? What > is 'g' in the block assigned to f? > > Is it required that 'g' be lexically defined prior to referencing it in a > block closure, or does Smalltalk have a mechanism to resolve this at > execution time? > > Thanks, > -Ted > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

May 16, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Brainstorms

Richard, Question from someone still fairly new to Smalltalk: To implement the example you gave regarding mutually recursive functions in Lua, one must write something like this: local f, g function g () <do something> f() <do something> end function f () <do something> g() <do something> end where the initial declaration of f & g as locals defines an f such that g will see it (as a local, albeit containing nil) when g is defined. The following definition of f doesn't require this, of course. And g doesn't care what f contains -- until execution time. Both Lua and Smalltalk implement full lexical closures, so it begs the question: Do the blocks defined in your example have this same issue? What is 'g' in the block assigned to f? Is it required that 'g' be lexically defined prior to referencing it in a block closure, or does Smalltalk have a mechanism to resolve this at execution time? Thanks, -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 15, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Richard O'Keefe

Suppose you want a pair of mutually recursive functions. They have to be able to name each other. In languages like Python and Ruby, you can have methods AND you can have named functions. In fact Python had named functions before it had objects. But in Smalltalk, you have methods, which cannot be invoked without mentioning the receiver, and you have blocks, which do NOT have a receiver of their own. So you have to write f := [:... | ... g value: ... ]. g := [:... | ... f value: ... ]. This also applies when f needs to call itself. At this point, Smalltalk beginners are so used to seeing blocks used directly as arguments that they use methods instead. On Thu, 16 May 2019 at 07:49, Hilaire <hilaire(a)drgeo.eu> wrote: > Le 15/05/2019 Ã 20:37, Konrad Hinsen a Ã©crit : > > Lambda expressions are indeed Python's anonymous functions, but no > > Python programmer would create a lambda expression only to assign it > > to a variable. Doing this in an article to "sell" Smalltalk might well > > have the opposite effect. > > Nor a Smalltalk programmer. > > Bellow the context for FYI. > > | sketch f df xn ptA ptB| > sketch := DrGeoSketch new axesOn. > xn := 2. > f := [ :x | x cos + x ]. > df := [ :x | (f value: x + 1e-8) - (f value: x) * 1e8]. "Derivate number" > sketch plot: f from: -20 to: 20. > ptA := (sketch point: xn@0) large; name: 'Drag me'. > 5 timesRepeat: [ > ptB := sketch point: [ :pt | pt point x @ (f value: pt point x)] > parent: ptA. > ptB hide. > (sketch segment: ptA to: ptB) dotted forwardArrow . > ptA := sketch point: [:pt | > | x | > x := pt point x. > x - ( (f value: x) / (df value: x) ) @ 0 ] parent: ptB. > ptA hide. > (sketch segment: ptB to: ptA) dotted forwardArrow]. > > > -- > Dr. Geo > http://drgeo.eu > > > >

May 15, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by BrunoBB

Hi, Blocks are very useful when you need to evaluate code from an outside source. For example a BPM Process that have gateways with different conditions. To the Smalltalk system conditions come as Strings and convert them to Smalltalk objects is very easy: self evaluate: '[:process | process amount > 1500]'. "condition inside a gateway of a process" And we have the block to evaluate and get the Boolean (to see what transition follow after the gateway). In other languages you have to process the condition String and do some kind of interpretation but is much more limited than a block. Of course there is a security issue here but very easy to overcome with an AST. If the conditions is: 'Smalltalk become: nil'. In my case all message can be sent to the block argument only and some other simple rules. regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 15, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Esteban Maringolo

On Wed, May 15, 2019 at 5:21 PM Tim Mackinnon <tim(a)testit.works> wrote: > > On a similar line - Iâve often noticed that an interesting block pattern in Smalltalk which is overlooked in other languages is how we handle errors through them. > > We often donât throw exceptions but instead pass a useful block (and often 2) for what to do instead. > > at:ifAbsent: comes to mind or at:ifPreset:ifAbsent: leading you to do interesting things yourself like parseSource:onErrorRecoverWith: (or whatever). > > I think this makes an interesting point about our block flexibility. Although it is not exactly the same, the async style of programming JavaScript uses similar approaches by passing "callback functions" as arguments to certain functions. e.g. fopen('/path/to/file', successFunction, errorHandler). As said, it is not exactly the same thing, and 100% callback programs can be a hell to work with, but the idiom of passing "lambdas" around is similar. Regards, Esteban A. Maringolo

May 15, 2019

Re: [Pharo-users] Bloc of code in tiers programming language

by Tim Mackinnon

On a similar line - Iâve often noticed that an interesting block pattern in Smalltalk which is overlooked in other languages is how we handle errors through them. We often donât throw exceptions but instead pass a useful block (and often 2) for what to do instead. at:ifAbsent: comes to mind or at:ifPreset:ifAbsent: leading you to do interesting things yourself like parseSource:onErrorRecoverWith: (or whatever). I think this makes an interesting point about our block flexibility. Tim Sent from my iPhone Sent from my iPhone >> On 15 May 2019, at 19:37, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: >> >> Am 15.05.19 um 15:26 schrieb Atharva Khare: >> >> I think in python, you use Lambda Expressions. Here is how I would do it in python3: >> import math >> f = lambda x: math.cos(x) + x >> d_f = lambda x: (f(x + 1e-8) - f(x)) * 1e8 > > Lambda expressions are indeed Python's anonymous functions, but no Python programmer would create a lambda expression only to assign it to a variable. Doing this in an article to "sell" Smalltalk might well have the opposite effect. > > Konrad. >

May 15, 2019