August 2021 - Pharo-users - lists.pharo.org

Re: Silly question about storing and displaying currency amounts?

by Guillermo Polito

Hi all, In the past months I worked a bit with it and found many problems too, like: - doing scaled decimal arithmetics losing precision https://github.com/pharo-project/pharo/issues/8668 - strange default scale values https://github.com/pharo-project/pharo/issues/8669 I also got hit with âdowngrading" issues during my vacation coding. For example, when operating a scaled decimal with a float, the result gets downgraded to a float. See 17.777 asScaledDecimal + 0.0 >From all the comments I understand that the current implementation is not very useful, they all lead to âdo not use it, instead do XXXâ where XXX is either - write your own - load that other package - use an integer to represent pennies This this means that either it can be removed, or it can benefit with a new and better implementation. I think it would be interesting to have a better ScaledDecimal implementation, that not only does precise printing but also precise arithmetics. Or maybe somebody has a good implementation already available? Cheers, Guille > El 31 ago 2021, a las 0:58, Richard O'Keefe <raoknz(a)gmail.com> escribiÃ³: > > Ah, you have run into the insufficiently well known > "ScaledDecimal looks like what you need but isn't". > > In VisualAge, you have a data type that is basically a reflection of iBM > mainframe "packed decimal" format, and perfectly suits the needs of > an SQL or COBOL interface. It gives you round-tripping with no error. > > In my Smalltalk, ScaledDecimal is a pair (n,s) where n and s are > unrestricted integers, representing n * (10 raisedTo: s). This also > gives you exact round-tripping and suits the needs of an SQL or COBOL > interface. > > However, in Squeak and Pharo, ScaledDecimal is something else > entirely. Basically, a pair (q,s) where q is an Integer or Fraction, > and s is a scale factor used for *printing*. This doesn't just lead to > oddities like two unequal ScaledDecimals printing identically, it > leads to rounding issues. This is not a bug, it is ScaledDecimal working > as designed. > > Working within Squeak, the simplest approach is to represent money as > pence, and the next simplest is to make or find a Money class. > > On Tue, 31 Aug 2021 at 00:02, David Pennington <david(a)totallyobjects.com> wrote: >> >> Hi everyone. I have a little bank analysis package for my own use but having trouble displaying and storing amounts. I parse out a CSV file from the bank and convert the amounts from text to ScaledDecimal. I then store these into a STON file, which converts them back to text. I then read them in and convert them back to ScaledDecimal again. >> >> I am not used to ~Pharo have spent 24 years using VisualAge Smalltalk so I need a little bit of help because I am getting 1 Penny errors in the conversions. I can cope with this but I would like to get it right. >> >> Can anyone give me a simple means of managing, say, an amount like Â£76.49 from the bank so that it stops coming back to me as Â£76.48? >> >> David >> Totally Objects

Aug. 31, 2021

Re: Silly question about storing and displaying currency amounts?

by Richard O'Keefe

Ah, you have run into the insufficiently well known "ScaledDecimal looks like what you need but isn't". In VisualAge, you have a data type that is basically a reflection of iBM mainframe "packed decimal" format, and perfectly suits the needs of an SQL or COBOL interface. It gives you round-tripping with no error. In my Smalltalk, ScaledDecimal is a pair (n,s) where n and s are unrestricted integers, representing n * (10 raisedTo: s). This also gives you exact round-tripping and suits the needs of an SQL or COBOL interface. However, in Squeak and Pharo, ScaledDecimal is something else entirely. Basically, a pair (q,s) where q is an Integer or Fraction, and s is a scale factor used for *printing*. This doesn't just lead to oddities like two unequal ScaledDecimals printing identically, it leads to rounding issues. This is not a bug, it is ScaledDecimal working as designed. Working within Squeak, the simplest approach is to represent money as pence, and the next simplest is to make or find a Money class. On Tue, 31 Aug 2021 at 00:02, David Pennington <david(a)totallyobjects.com> wrote: > > Hi everyone. I have a little bank analysis package for my own use but having trouble displaying and storing amounts. I parse out a CSV file from the bank and convert the amounts from text to ScaledDecimal. I then store these into a STON file, which converts them back to text. I then read them in and convert them back to ScaledDecimal again. > > I am not used to ~Pharo have spent 24 years using VisualAge Smalltalk so I need a little bit of help because I am getting 1 Penny errors in the conversions. I can cope with this but I would like to get it right. > > Can anyone give me a simple means of managing, say, an amount like Â£76.49 from the bank so that it stops coming back to me as Â£76.48? > > David > Totally Objects

Aug. 30, 2021

Re: Silly question about storing and displaying currency amounts?

by Esteban Maringolo

I was recently bitten by this wrong "scaled decimal expectation", in which what I thought was wrong it actually wasn't, or I can't tell whether it was. I would expect that a scaled decimal would be something like what Esteban L. suggests, an integer where you just move the decimal point for printing, and also a number where you lose precision due to truncation. So this: ((1.0s2 / 3) * 3) + 0.01s2 Would yield 1 instead of "1.01s2" So if you use the "integer only" representation, it is very much like any currency number would me managed: ((100 / 3) truncated * 3 + 1) / 100 This, of course, yields the right value, but it started truncated from the beginning. (0.33s2 * 3) + 0.01s2 "1" I would appreciate any pointers about learning more about this. It's embarrassing for me not knowing how each type should work in order to tell what's right from what's wrong. Regards! ps: In my case this wasn't because of money, but another kind of use, but the situation is the same. Esteban A. Maringolo On Mon, Aug 30, 2021 at 9:51 AM Esteban Lorenzano <estebanlm(a)netc.eu> wrote: > > hi, > > some time ago there was a "money" package around, that basically had a Currency type that internally stored values as integers (like, 42.0 was becoming 4200). This had some advantages to make this kind of calculus (also, it has the "other" advantage of making you believe that you have a lot more money than what you have ;). > > maybe you need to go that direction? > > Esteban > > On Aug 30 2021, at 2:31 pm, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > David, > > > On 30 Aug 2021, at 14:02, David Pennington <david(a)totallyobjects.com> wrote: > > > > Hi everyone. I have a little bank analysis package for my own use but having trouble displaying and storing amounts. I parse out a CSV file from the bank and convert the amounts from text to ScaledDecimal. I then store these into a STON file, which converts them back to text. I then read them in and convert them back to ScaledDecimal again. > > > > I am not used to ~Pharo have spent 24 years using VisualAge Smalltalk so I need a little bit of help because I am getting 1 Penny errors in the conversions. I can cope with this but I would like to get it right. > > > > Can anyone give me a simple means of managing, say, an amount like Â£76.49 from the bank so that it stops coming back to me as Â£76.48? > > > > David > > Totally Objects > > Working with money is always challenging. I know that many people say 'Use ScaledDecimal' as if that magically solves all problems but it does not. ScaledDecimal is a bit of a dangerous class to use. It is just a fraction with a certain precision. Internally it might be pretty accurate with respect to most operations, its external representation as floating point number can be misleading, as this representation is prone to all problems related to floating point (including the fact that decimal and binary floating point are not the same). > > STON does not doing anything wrong as far as I know. Consider the following: > > | amount ston | > amount := 76.49 asScaledDecimal. > ston := STON toString: amount. > STON fromString: ston. > (STON fromString: ston) = amount. > "true" > > | amount ston | > amount := 76.49 asScaledDecimal: 2. > ston := STON toString: amount. > STON fromString: ston. > (STON fromString: ston) = amount. > "true" > > | amount ston | > amount := 76.49. > ston := STON toString: amount. > STON fromString: ston. > (STON fromString: ston) = amount. > "true" > > BUT, 76.49 asScaledDecimal already has your penny loss (if rounded to pennies). > > HTH, > > Sven

Aug. 30, 2021

Re: Silly question about storing and displaying currency amounts?

by David Pennington

I come from a currency trader background and way back in 1983, I was dealing with this in North Star Basic and then UCSD Pascal and into VisualSmalltalk (remember that?) so I have some history here. Trouble is, at 76, my little grey cells are letting me down bit. Excuses over. I will go back into the code and make sure that I scale all these ScaledDecimals to 2 and see if that helps. BTW, I wasnât suggesting that there was any problem with STON as that works brilliantly for me. David > On 30 Aug 2021, at 13:51, jtuchel(a)objektfabrik.de wrote: > > Hi Sven, > > > I just tried 46.79 asScaledDecimal and 46.79 asScaledDecimal: 2 in both VAST and Pharo and see quite different results. > In VAST, not providing a scale returns 46.79, but with a scale of 14 (46.79s14). But it is still 46.79. > > What's good is that the results of "asScaledDecimal: 2" yields the same results on VAST and Pharo. > > Your examples also use a fixed scale of 2. So is it safe to assume that when you provide the scale, ScaledDecimal is good for monetary amounts in Pharo? I ask because that is what I once learned in an IBM training decades ago: use ScaledDecimals for money and percentages, never use floats. > > Would you agree that as a rule of thumb, Pounds, Dollars and Euros are safely stored and processed when you make sure to always provide the scale of 2 (unless you manage stock or petrol prices which use 3 or 4 or even more digits)? > > Joachim > > > > > > Am 30.08.21 um 14:31 schrieb Sven Van Caekenberghe: >> David, >> >>> On 30 Aug 2021, at 14:02, David Pennington <david(a)totallyobjects.com> wrote: >>> >>> Hi everyone. I have a little bank analysis package for my own use but having trouble displaying and storing amounts. I parse out a CSV file from the bank and convert the amounts from text to ScaledDecimal. I then store these into a STON file, which converts them back to text. I then read them in and convert them back to ScaledDecimal again. >>> >>> I am not used to ~Pharo have spent 24 years using VisualAge Smalltalk so I need a little bit of help because I am getting 1 Penny errors in the conversions. I can cope with this but I would like to get it right. >>> >>> Can anyone give me a simple means of managing, say, an amount like Â£76.49 from the bank so that it stops coming back to me as Â£76.48? >>> >>> David >>> Totally Objects >> Working with money is always challenging. I know that many people say 'Use ScaledDecimal' as if that magically solves all problems but it does not. ScaledDecimal is a bit of a dangerous class to use. It is just a fraction with a certain precision. Internally it might be pretty accurate with respect to most operations, its external representation as floating point number can be misleading, as this representation is prone to all problems related to floating point (including the fact that decimal and binary floating point are not the same). >> >> STON does not doing anything wrong as far as I know. Consider the following: >> >> | amount ston | >> amount := 76.49 asScaledDecimal. >> ston := STON toString: amount. >> STON fromString: ston. >> (STON fromString: ston) = amount. >> "true" >> >> | amount ston | >> amount := 76.49 asScaledDecimal: 2. >> ston := STON toString: amount. >> STON fromString: ston. >> (STON fromString: ston) = amount. >> "true" >> >> | amount ston | >> amount := 76.49. >> ston := STON toString: amount. >> STON fromString: ston. >> (STON fromString: ston) = amount. >> "true" >> >> BUT, 76.49 asScaledDecimal already has your penny loss (if rounded to pennies). >> >> HTH, >> >> Sven >> > > -- > ----------------------------------------------------------------------- > 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 >

Aug. 30, 2021

Re: Silly question about storing and displaying currency amounts?

by Sabine Manaa

http://smalltalkhub.com/pdebruic/Money/index.html Am Mo., 30. Aug. 2021 um 14:51 Uhr schrieb jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de>: > Hi Sven, > > > I just tried 46.79 asScaledDecimal and 46.79 asScaledDecimal: 2 in both > VAST and Pharo and see quite different results. > In VAST, not providing a scale returns 46.79, but with a scale of 14 > (46.79s14). But it is still 46.79. > > What's good is that the results of "asScaledDecimal: 2" yields the same > results on VAST and Pharo. > > Your examples also use a fixed scale of 2. So is it safe to assume that > when you provide the scale, ScaledDecimal is good for monetary amounts > in Pharo? I ask because that is what I once learned in an IBM training > decades ago: use ScaledDecimals for money and percentages, never use > floats. > > Would you agree that as a rule of thumb, Pounds, Dollars and Euros are > safely stored and processed when you make sure to always provide the > scale of 2 (unless you manage stock or petrol prices which use 3 or 4 or > even more digits)? > > Joachim > > > > > > Am 30.08.21 um 14:31 schrieb Sven Van Caekenberghe: > > David, > > > >> On 30 Aug 2021, at 14:02, David Pennington <david(a)totallyobjects.com> > wrote: > >> > >> Hi everyone. I have a little bank analysis package for my own use but > having trouble displaying and storing amounts. I parse out a CSV file from > the bank and convert the amounts from text to ScaledDecimal. I then store > these into a STON file, which converts them back to text. I then read them > in and convert them back to ScaledDecimal again. > >> > >> I am not used to ~Pharo have spent 24 years using VisualAge Smalltalk > so I need a little bit of help because I am getting 1 Penny errors in the > conversions. I can cope with this but I would like to get it right. > >> > >> Can anyone give me a simple means of managing, say, an amount like > Â£76.49 from the bank so that it stops coming back to me as Â£76.48? > >> > >> David > >> Totally Objects > > Working with money is always challenging. I know that many people say > 'Use ScaledDecimal' as if that magically solves all problems but it does > not. ScaledDecimal is a bit of a dangerous class to use. It is just a > fraction with a certain precision. Internally it might be pretty accurate > with respect to most operations, its external representation as floating > point number can be misleading, as this representation is prone to all > problems related to floating point (including the fact that decimal and > binary floating point are not the same). > > > > STON does not doing anything wrong as far as I know. Consider the > following: > > > > | amount ston | > > amount := 76.49 asScaledDecimal. > > ston := STON toString: amount. > > STON fromString: ston. > > (STON fromString: ston) = amount. > > "true" > > > > | amount ston | > > amount := 76.49 asScaledDecimal: 2. > > ston := STON toString: amount. > > STON fromString: ston. > > (STON fromString: ston) = amount. > > "true" > > > > | amount ston | > > amount := 76.49. > > ston := STON toString: amount. > > STON fromString: ston. > > (STON fromString: ston) = amount. > > "true" > > > > BUT, 76.49 asScaledDecimal already has your penny loss (if rounded to > pennies). > > > > HTH, > > > > Sven > > > > -- > ----------------------------------------------------------------------- > 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 > >

Aug. 30, 2021

Re: Silly question about storing and displaying currency amounts?

by jtuchel＠objektfabrik.de

Hi Sven, I just tried 46.79 asScaledDecimal and 46.79 asScaledDecimal: 2 in both VAST and Pharo and see quite different results. In VAST, not providing a scale returns 46.79, but with a scale of 14 (46.79s14). But it is still 46.79. What's good is that the results of "asScaledDecimal: 2" yields the same results on VAST and Pharo. Your examples also use a fixed scale of 2. So is it safe to assume that when you provide the scale, ScaledDecimal is good for monetary amounts in Pharo? I ask because that is what I once learned in an IBM training decades ago: use ScaledDecimals for money and percentages, never use floats. Would you agree that as a rule of thumb, Pounds, Dollars and Euros are safely stored and processed when you make sure to always provide the scale of 2 (unless you manage stock or petrol prices which use 3 or 4 or even more digits)? Joachim Am 30.08.21 um 14:31 schrieb Sven Van Caekenberghe: > David, > >> On 30 Aug 2021, at 14:02, David Pennington <david(a)totallyobjects.com> wrote: >> >> Hi everyone. I have a little bank analysis package for my own use but having trouble displaying and storing amounts. I parse out a CSV file from the bank and convert the amounts from text to ScaledDecimal. I then store these into a STON file, which converts them back to text. I then read them in and convert them back to ScaledDecimal again. >> >> I am not used to ~Pharo have spent 24 years using VisualAge Smalltalk so I need a little bit of help because I am getting 1 Penny errors in the conversions. I can cope with this but I would like to get it right. >> >> Can anyone give me a simple means of managing, say, an amount like Â£76.49 from the bank so that it stops coming back to me as Â£76.48? >> >> David >> Totally Objects > Working with money is always challenging. I know that many people say 'Use ScaledDecimal' as if that magically solves all problems but it does not. ScaledDecimal is a bit of a dangerous class to use. It is just a fraction with a certain precision. Internally it might be pretty accurate with respect to most operations, its external representation as floating point number can be misleading, as this representation is prone to all problems related to floating point (including the fact that decimal and binary floating point are not the same). > > STON does not doing anything wrong as far as I know. Consider the following: > > | amount ston | > amount := 76.49 asScaledDecimal. > ston := STON toString: amount. > STON fromString: ston. > (STON fromString: ston) = amount. > "true" > > | amount ston | > amount := 76.49 asScaledDecimal: 2. > ston := STON toString: amount. > STON fromString: ston. > (STON fromString: ston) = amount. > "true" > > | amount ston | > amount := 76.49. > ston := STON toString: amount. > STON fromString: ston. > (STON fromString: ston) = amount. > "true" > > BUT, 76.49 asScaledDecimal already has your penny loss (if rounded to pennies). > > HTH, > > Sven > -- ----------------------------------------------------------------------- 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

Aug. 30, 2021

Re: Silly question about storing and displaying currency amounts?

by Esteban Lorenzano

hi, some time ago there was a "money" package around, that basically had a Currency type that internally stored values as integers (like, 42.0 was becoming 4200). This had some advantages to make this kind of calculus (also, it has the "other" advantage of making you believe that you have a lot more money than what you have ;). maybe you need to go that direction? Esteban On Aug 30 2021, at 2:31 pm, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > David, > > > On 30 Aug 2021, at 14:02, David Pennington <david(a)totallyobjects.com> wrote: > > > > Hi everyone. I have a little bank analysis package for my own use but having trouble displaying and storing amounts. I parse out a CSV file from the bank and convert the amounts from text to ScaledDecimal. I then store these into a STON file, which converts them back to text. I then read them in and convert them back to ScaledDecimal again. > > > > I am not used to ~Pharo have spent 24 years using VisualAge Smalltalk so I need a little bit of help because I am getting 1 Penny errors in the conversions. I can cope with this but I would like to get it right. > > > > Can anyone give me a simple means of managing, say, an amount like Â£76.49 from the bank so that it stops coming back to me as Â£76.48? > > > > David > > Totally Objects > > Working with money is always challenging. I know that many people say 'Use ScaledDecimal' as if that magically solves all problems but it does not. ScaledDecimal is a bit of a dangerous class to use. It is just a fraction with a certain precision. Internally it might be pretty accurate with respect to most operations, its external representation as floating point number can be misleading, as this representation is prone to all problems related to floating point (including the fact that decimal and binary floating point are not the same). > STON does not doing anything wrong as far as I know. Consider the following: > | amount ston | > amount := 76.49 asScaledDecimal. > ston := STON toString: amount. > STON fromString: ston. > (STON fromString: ston) = amount. > "true" > > | amount ston | > amount := 76.49 asScaledDecimal: 2. > ston := STON toString: amount. > STON fromString: ston. > (STON fromString: ston) = amount. > "true" > > | amount ston | > amount := 76.49. > ston := STON toString: amount. > STON fromString: ston. > (STON fromString: ston) = amount. > "true" > > BUT, 76.49 asScaledDecimal already has your penny loss (if rounded to pennies). > HTH, > Sven

Aug. 30, 2021

Re: Silly question about storing and displaying currency amounts?

by Sven Van Caekenberghe

David, > On 30 Aug 2021, at 14:02, David Pennington <david(a)totallyobjects.com> wrote: > > Hi everyone. I have a little bank analysis package for my own use but having trouble displaying and storing amounts. I parse out a CSV file from the bank and convert the amounts from text to ScaledDecimal. I then store these into a STON file, which converts them back to text. I then read them in and convert them back to ScaledDecimal again. > > I am not used to ~Pharo have spent 24 years using VisualAge Smalltalk so I need a little bit of help because I am getting 1 Penny errors in the conversions. I can cope with this but I would like to get it right. > > Can anyone give me a simple means of managing, say, an amount like Â£76.49 from the bank so that it stops coming back to me as Â£76.48? > > David > Totally Objects Working with money is always challenging. I know that many people say 'Use ScaledDecimal' as if that magically solves all problems but it does not. ScaledDecimal is a bit of a dangerous class to use. It is just a fraction with a certain precision. Internally it might be pretty accurate with respect to most operations, its external representation as floating point number can be misleading, as this representation is prone to all problems related to floating point (including the fact that decimal and binary floating point are not the same). STON does not doing anything wrong as far as I know. Consider the following: | amount ston | amount := 76.49 asScaledDecimal. ston := STON toString: amount. STON fromString: ston. (STON fromString: ston) = amount. "true" | amount ston | amount := 76.49 asScaledDecimal: 2. ston := STON toString: amount. STON fromString: ston. (STON fromString: ston) = amount. "true" | amount ston | amount := 76.49. ston := STON toString: amount. STON fromString: ston. (STON fromString: ston) = amount. "true" BUT, 76.49 asScaledDecimal already has your penny loss (if rounded to pennies). HTH, Sven

Aug. 30, 2021

Silly question about storing and displaying currency amounts?

by David Pennington

Hi everyone. I have a little bank analysis package for my own use but having trouble displaying and storing amounts. I parse out a CSV file from the bank and convert the amounts from text to ScaledDecimal. I then store these into a STON file, which converts them back to text. I then read them in and convert them back to ScaledDecimal again. I am not used to ~Pharo have spent 24 years using VisualAge Smalltalk so I need a little bit of help because I am getting 1 Penny errors in the conversions. I can cope with this but I would like to get it right. Can anyone give me a simple means of managing, say, an amount like Â£76.49 from the bank so that it stops coming back to me as Â£76.48? David Totally Objects

Aug. 30, 2021

Re: The ideal font for Pharo

by Guillermo Polito

Hi tau, Thanks for it, Iâll check it :) > El 26 ago 2021, a las 1:17, tau <tau(a)cedalion.info> escribiÃ³: > > I've been bothered by the assignement operator (:=) and the way the colon and the equal sign aren't verticaly aligned when coding in Pharo. So I began a quest to find a pharo-friendly font were the colon and equal sign are aligned. Turn out most monospaced fonts don't qualify but I did find the following fonts: > > Fira Code (https://fontlibrary.org/en/font/fira-code <https://fontlibrary.org/en/font/fira-code>) has a := ligature that doesn't work in Pharo. > Iosevka extended (https://fontlibrary.org/en/font/iosevka-extended <https://fontlibrary.org/en/font/iosevka-extended>) also has a := ligature that doen't work in Pharo. > Mononoki (https://fontlibrary.org/en/font/mononoki <https://fontlibrary.org/en/font/mononoki>) has the two characters properly aligned but I dislike the appareance of that font. The @, in particular, looks like it comes from a low-resolution terminal from the early '80s. > Fantasque Sans Mono (https://fontlibrary.org/en/font/fantasque-sans-mono <https://fontlibrary.org/en/font/fantasque-sans-mono>) has perfectly aligned colon and equal sign and moreover has a nice informal look. > > So, Fantasque Sans Mono is now my favorite font for coding in Pharo ð.

Aug. 30, 2021

Re: uFFI: Calling conventions?

by Guillermo Polito

Hi egarrulo, > El 27 ago 2021, a las 18:50, egarrulo <egarrulo(a)gmail.com> escribiÃ³: > > >> Yesterday we have implemented the image side part in P10 to correctly > honour the calling convention. > > Does this imply that uFFI doesn't work correctly on current images? > Because uFFI should have been available since Pharo 8, according to the > uFFI manual. Or is it a revamped implementation? Calling conventions are properly working, but I think that what Pablo means is something else. The current implementation just uses the most common (which is the sole in most cases) calling convention for the platform. What Pablo meant I think is that the current implementation does not allow users to redefine the calling convention. > >> On the other hand, you are asking about ThisCall. This calling > conventionis only relevant in 32bits systems. What is your target > system/library? Does it not exist as 64-bit library? > > Unfortunately it is a legacy library with no 64 bit version. No problem, > because I can write a wrapper, yet I was wondering if Pharo offered any > facilities to avoid that. Check Pabloâs PR https://github.com/pharo-project/pharo/pull/9826 The class TFUFFIDifferentCallingConventionFunctionCallTest uses the ffiCallingConvention hook to decide what calling convention to use. Check the list in initializeABIMapping to see the available calling conventions. Cheers, G > > Thank you for the information. > > ---------------------------------------------------------------------- >> Message: 1 >> Date: Thu, 26 Aug 2021 15:38:48 +0200 >> From: "tesonep(a)gmail.com" <tesonep(a)gmail.com> >> Subject: [Pharo-users] Re: uFFI: Calling conventions? >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> Message-ID: >> <CAM9-ED+DYAJdOF0GfBcypmV9cQqufmSzUmC51EaLRzS2ycsPWQ(a)mail.gmail.com> >> Content-Type: multipart/alternative; >> boundary="0000000000004711e205ca767def" >> >> Hi All, >> The answer is yes and no. >> Let's go step by step. >> To declare the calling convention a class can override the method >> #ffiCallingConvention. Returning a Symbol representing the Calling >> Convention. >> >> Yesterday we have implemented the image side part in P10 to correctly >> honour the calling convention. >> I have implemented it for X86 but this can be easily extended to ARM32 >> (ARM64 has a single calling convention). >> If this fix is useful, it can be backported to P9. >> >> However, this only works for X86_64 as it depends on the new FFI >> implementation. We still do not have an X86 32 bits VM, it is possible to >> compile it from sources, but we are not distributing it. >> >> In X86_64 only exists the Windows and the GNU calling convention, we are >> supporting both. >> >> On the other hand, you are asking about ThisCall. This calling convention >> is only relevant in 32bits systems. What is your target system/library? >> Does it not exist as 64-bit library? >> >> Thanks >> >> On Tue, Aug 24, 2021 at 9:33 PM egarrulo <egarrulo(a)gmail.com> wrote: >> >>> Hi all, >>> >>> I haven't found any information on calling conventions in the "Unified >>> FFI - Calling Foreign Functions from Pharo" manual. What conventions are >>> available, please? >>> >>> If the ThisCall[1] convention isn't supported, could it be implemented >>> in code with some boilerplate? >>> >>> Thank you. >>> >>> -- >>> >>> [1] ThisCall works like StdCall, but the first parameter - the "this" >>> pointer - is passed via the ECX register. >>> >>>

Aug. 30, 2021

Re: Using new VM but can't find any log files

by David Pennington

Sven Thanks for your response. I had the same problem on 8.0 and, in fact, had the same problem with VAST on Windows 10 and Windows 2012 server so I am not hopeful. Running Linux is not an option for me although I could reconfigure my Windows 2012 Server as I have replaced that with an M1 MacMini. For the time being, my client (or at least the club that I belong to, appreciate my efforts and are happy with as minimal HTML web site and a Blog but I got the MacMini hoping to solve this so I would like to see a solution. I am enjoying Pharo and donât want. To have to leave it. David > On 28 Aug 2021, at 16:47, David Pennington <david(a)totallyobjects.com> wrote: > > Hi there. I have installed the new M1 VM that supposedly gives much better information into a log file. However, my image is still disappearing such that it now doesnât last more than 12 hours before going. I have searched for these log files but I canât find any. Can anyone help me in this as I am close the throwing this all into the bin if I canât keep my simple web site going regularly. My clients are not happy, as you can imagine and telling me to just go with a Blogger blog! I donât want to do that so can anyone help? > David

Aug. 28, 2021

Re: Using new VM but can't find any log files

by Sven Van Caekenberghe

David, > On 28 Aug 2021, at 17:47, David Pennington <david(a)totallyobjects.com> wrote: > > Hi there. I have installed the new M1 VM that supposedly gives much better information into a log file. However, my image is still disappearing such that it now doesnât last more than 12 hours before going. I have searched for these log files but I canât find any. Can anyone help me in this as I am close the throwing this all into the bin if I canât keep my simple web site going regularly. My clients are not happy, as you can imagine and telling me to just go with a Blogger blog! I donât want to do that so can anyone help? > David We are sorry that you have this problem. Many people have already interacted with you via various channels. Multiple Pharo developers are working on this issue (https://github.com/pharo-project/pharo/issues/9565) but right now there is no immediate solution. One option would be to go back to Pharo 7 or 8 (it is normally easy to have the same code base for Pharo 7, 8 and 9), but then you probably need to move away from M1 hardware. Another option would be to run your application under control of launchd (on macOS) os systemd (on Linux). These tools automatically restart your app when it goes down. This is something you need for proper production deployment anyway. In any case we are working on it and will surely let you know if we make progress. HTH, Sven

Aug. 28, 2021

Using new VM but can't find any log files

by David Pennington

Hi there. I have installed the new M1 VM that supposedly gives much better information into a log file. However, my image is still disappearing such that it now doesnât last more than 12 hours before going. I have searched for these log files but I canât find any. Can anyone help me in this as I am close the throwing this all into the bin if I canât keep my simple web site going regularly. My clients are not happy, as you can imagine and telling me to just go with a Blogger blog! I donât want to do that so can anyone help? David

Aug. 28, 2021

Re: uFFI: Calling conventions?

by egarrulo

>> Yesterday we have implemented the image side part in P10 to correctly Â Â honour the calling convention. Does this imply that uFFI doesn't work correctly on current images? Because uFFI should have been available since Pharo 8, according to the uFFI manual.Â Or is it a revamped implementation? >> On the other hand, you are asking about ThisCall. This calling Â Â conventionis only relevant in 32bits systems. What is your target Â Â system/library? Does it not exist as 64-bit library? Unfortunately it is a legacy library with no 64 bit version. No problem, because I can write a wrapper, yet I was wondering if Pharo offered any facilities to avoid that. Thank you for the information. ---------------------------------------------------------------------- > Message: 1 > Date: Thu, 26 Aug 2021 15:38:48 +0200 > From: "tesonep(a)gmail.com" <tesonep(a)gmail.com> > Subject: [Pharo-users] Re: uFFI: Calling conventions? > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Message-ID: > <CAM9-ED+DYAJdOF0GfBcypmV9cQqufmSzUmC51EaLRzS2ycsPWQ(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="0000000000004711e205ca767def" > > Hi All, > The answer is yes and no. > Let's go step by step. > To declare the calling convention a class can override the method > #ffiCallingConvention. Returning a Symbol representing the Calling > Convention. > > Yesterday we have implemented the image side part in P10 to correctly > honour the calling convention. > I have implemented it for X86 but this can be easily extended to ARM32 > (ARM64 has a single calling convention). > If this fix is useful, it can be backported to P9. > > However, this only works for X86_64 as it depends on the new FFI > implementation. We still do not have an X86 32 bits VM, it is possible to > compile it from sources, but we are not distributing it. > > In X86_64 only exists the Windows and the GNU calling convention, we are > supporting both. > > On the other hand, you are asking about ThisCall. This calling convention > is only relevant in 32bits systems. What is your target system/library? > Does it not exist as 64-bit library? > > Thanks > > On Tue, Aug 24, 2021 at 9:33 PM egarrulo <egarrulo(a)gmail.com> wrote: > >> Hi all, >> >> I haven't found any information on calling conventions in the "Unified >> FFI - Calling Foreign Functions from Pharo" manual. What conventions are >> available, please? >> >> If the ThisCall[1] convention isn't supported, could it be implemented >> in code with some boilerplate? >> >> Thank you. >> >> -- >> >> [1] ThisCall works like StdCall, but the first parameter - the "this" >> pointer - is passed via the ECX register. >> >>

Aug. 27, 2021

Re: uFFI: Calling conventions?

by tesonep＠gmail.com

Hi All, The answer is yes and no. Let's go step by step. To declare the calling convention a class can override the method #ffiCallingConvention. Returning a Symbol representing the Calling Convention. Yesterday we have implemented the image side part in P10 to correctly honour the calling convention. I have implemented it for X86 but this can be easily extended to ARM32 (ARM64 has a single calling convention). If this fix is useful, it can be backported to P9. However, this only works for X86_64 as it depends on the new FFI implementation. We still do not have an X86 32 bits VM, it is possible to compile it from sources, but we are not distributing it. In X86_64 only exists the Windows and the GNU calling convention, we are supporting both. On the other hand, you are asking about ThisCall. This calling convention is only relevant in 32bits systems. What is your target system/library? Does it not exist as 64-bit library? Thanks On Tue, Aug 24, 2021 at 9:33 PM egarrulo <egarrulo(a)gmail.com> wrote: > Hi all, > > I haven't found any information on calling conventions in the "Unified > FFI - Calling Foreign Functions from Pharo" manual. What conventions are > available, please? > > If the ThisCall[1] convention isn't supported, could it be implemented > in code with some boilerplate? > > Thank you. > > -- > > [1] ThisCall works like StdCall, but the first parameter - the "this" > pointer - is passed via the ECX register. > > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 26, 2021

The ideal font for Pharo

by tau

I've been bothered by the assignement operator (:=) and the way the colon and the equal sign aren't verticaly aligned when coding in Pharo. So I began a quest to find a pharo-friendly font were the colon and equal sign are aligned. Turn out most monospaced fonts don't qualify but I did find the following fonts: * Fira Code (https://fontlibrary.org/en/font/fira-code) has a := ligature that doesn't work in Pharo. * Iosevka extended (https://fontlibrary.org/en/font/iosevka-extended) also has a := ligature that doen't work in Pharo. * Mononoki (https://fontlibrary.org/en/font/mononoki) has the two characters properly aligned but I dislike the appareance of that font. The @, in particular, looks like it comes from a low-resolution terminal from the early '80s. * Fantasque Sans Mono (https://fontlibrary.org/en/font/fantasque-sans-mono) has perfectly aligned colon and equal sign and moreover has a nice informal look. So, Fantasque Sans Mono is now my favorite font for coding in Pharo ð.

Aug. 25, 2021

uFFI: Calling conventions?

by egarrulo

Hi all, I haven't found any information on calling conventions in the "Unified FFI - Calling Foreign Functions from Pharo" manual. What conventions are available, please? If the ThisCall[1] convention isn't supported, could it be implemented in code with some boilerplate? Thank you. -- [1] ThisCall works like StdCall, but the first parameter - the "this" pointer - is passed via the ECX register.

Aug. 24, 2021

Re: Private Methods

by Tim Mackinnon

You are very right - it hadnât sunk in that a compiled method attribute would give you what you want - but then we are back to an easily extendible browser â¦ which I think calypso actually is â¦ hmm should be quite easily doable to get all described here - and show private methods in a private category like Dolphin did (somewhat related, I wish class methods worked this way too - I hate flipping between class/instance mode) Anyway, a great topic for making you think a bit more. Tim > On 23 Aug 2021, at 15:06, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > ï»¿If something, I'd rather have _ as a prefix indicating a private > method, very much like Dart does. > But why use a "syntax" trick when it could be an attribute of the > CompiledMethod itself? > > As for many private methods being a code smell... it could be, but it > depends, until you find the right abstractions you might want to keep > private all the stuff that is causing the smell :-) > > > > > Esteban A. Maringolo > >> On Mon, Aug 23, 2021 at 8:06 AM Tim Mackinnon <tim(a)testit.works> wrote: >> >> As many have described, Iâve seen this work reasonably well too - while Iâve seen the pvt prefix convention, Iâve also seen _name used to - which I felt was marginally better (it also means private methods get grouped at the top of the âall listâ and not alphabetically in the middleâish (but itâs a minor thing as browser tools can filter appropriately anyway, and to be honest, showing private at the bottom or in a separate place is better). >> >> It is worth saying however - that lots if pvt methods can be a code smell - it may be better to move them to a separate âpolicy objectâ and then focus on better delegation options - which I believe is where Pharo is heading with variables as first class objects (and hopefully Marcus will cover in the U.K. Smalltalk Meetup this week). >> >> Too often we end up up with lots of sub classing and overriding and privatising - when there is a new object that could group all this stuff and the methods can be public in that delegate - while the delegate itself is a âprivateâ object. >> >> I think this should be explored more actually. >> >> Tim >> >>>> On 20 Aug 2021, at 11:19, Richard O'Keefe <raoknz(a)gmail.com> wrote: >>> >>> ï»¿One of the claimed benefits of object-oriented programming is ENCAPSULATION. >>> The idea is that one of the ways a language helps you is by making some errors >>> difficult or impossible to express. >>> One of the things you need to understand an object is its INVARIANT. >>> For example, astc's SortedCollection includes >>> >>> methods for: 'checking' >>> invariant >>> ^(opposite isNil or: [ >>> opposite isKindOf: DyadicBlock]) and: [ >>> super invariant and: [ >>> (sortBlock >>> ifNil: [(offset + 2 to: offset + size) allSatisfy: [:i | >>> (array at: i-1) <= (array at: i)]] >>> ifNotNil: [(sortBlock respondsTo: #value:value:) and: [ >>> [(offset + 2 to: offset + size) allSatisfy: [:i | >>> (sortBlock value: (array at: i-1) >>> value: (array at: i))]]]])]] >>> >>> Private methods are allowed to break the invariant. >>> Public methods are not. >>> >>> For example, consider reversing a SortedCollection. >>> Part of this changes the order of the elements, and can be >>> shared with OrderedCollection. Part of it swaps the arguments >>> of the sortBlock, and cannot be shared. >>> >>> methods for: 'rearranging' >>> pvtPrereverse >>> |t| >>> opposite >>> ifNil: [ >>> sortBlock ifNil: [sortBlock := Magnitude defaultSortBlock]. >>> t := sortBlock. >>> opposite := sortBlock. >>> sortBlock := [:x :y | t value: y value: x]] >>> ifNotNil: [ >>> t := sortBlock. >>> sortBlock := opposite. >>> opposite := t]. >>> >>> If this method could be called from "outside", it would certainly break >>> the invariant and leave the object in an unusable state. >>> >>> Now a style rule doesn't *quite* prevent this method being called by >>> another object. >>> It is necessary to make sure that #perform: and friends cannot break >>> encapsulation >>> either, and this astc does by simply not creating Selector objects for >>> private methods. >>> >>> Yes, it is a small increase in the complexity of the language, however >>> - you are not forced to write private methods >>> - if you run code that uses the pvt* convention in a Smalltalk that does >>> not use that convention, it works, it's just not safe any longer >>> - it is not an arbitrary addition to the language, it is a restriction that >>> makes programming *easier*. >>> >>> Let's look at one additional example. >>> Behavior>> >>> new >>> ^ self basicNew initialize >>> >>> This means that *any* object can forcibly reinitialize *any* object it can >>> reach at *any* time. In astc, it's >>> >>> new >>> "other checks" >>> ^self pvtNew pvtPostNew >>> >>> and an object cannot be reinitialised against its will. >>> >>> There is a long standing tradition of "program for the typical case and trust >>> the omniscient programmer to know what will probably work and what won't" >>> in Smalltalk. This is why in many Smalltalks >>> aCollection addAll: aCollection >>> or >>> aCollection removeAll: aCollection >>> can go insane for some common collections. And one *DOES* get away >>> with it most of the time. It's typically when someone else triest to use your >>> code and doesn't know the assumptions you didn't bother to write down >>> that things go wrong. It's obvious that Pharo has got to where it >>> amazingly well is without the "bondage and discipline" of, say, Ada or >>> Agda. But there is a *reason* why Pharo has lint checking on by default. >>> >>>> On Fri, 20 Aug 2021 at 00:59, Jesus Mari Aguirre <jmariaguirre(a)gmail.com> wrote: >>>> >>>> Please keep Pharo simple, why do you need private methods...you can include then in a protocol named private...other language have it...yes...next addition will be namespaces...other...I don't know...at last we have Java >>>> >>>> El jue., 19 ago. 2021 9:00, Richard O'Keefe <raoknz(a)gmail.com> escribiÃ³: >>>>> >>>>> Many years ago there was a proposal in the Squeak mailing list about enforcing >>>>> a naming convention, "pvt", I implemented that in my Smalltalk system. The >>>>> compiler enforces the rule that pvt.[A-Z].* message can only be sent to >>>>> (self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)? >>>>> in a class method or >>>>> (self|super) ((class (new|new: n)|pvtSpeciesNew: n|pvtClone)? >>>>> in an instance method. >>>>> There are currently >>>>> 9412 public selectors >>>>> 793 pvt* selectors and >>>>> 23 private* selectors, >>>>> where the last group is methods that I *want* to be private in some sense but >>>>> cannot do with this machinery. (For example, calling a "private" method on >>>>> another object known to be of the same class.) >>>>> >>>>> I think the evidence shows that this works well enough to be useful, even if it >>>>> isn't quite as expressive as I'd like. And what *that* means is that >>>>> this can be >>>>> done with a style check, using the machinery Pharo already has for style checks. >>>>> >>>>> >>>>> >>>>> On Wed, 18 Aug 2021 at 08:14, Craig Johnson <craig(a)hivemind.net> wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> >>>>>> Just a newb off-the-wall question. >>>>>> >>>>>> Is there any good reason why we can't create a true private method in a >>>>>> Pharo class by putting that method inside an instance or class variable >>>>>> as a lambda (block). >>>>>> >>>>>> >>>>>> This would reduce one of my biggest bugbears with Pharo, namely the >>>>>> pollution of the global namespace with every single message name in the >>>>>> entire system. >>>>>> >>>>>> >>>>>> >>>>>> Craig

Aug. 23, 2021

Re: Private Methods

by Torsten Bergmann

Hi, Smalltalk should be readable - so I dislike the prefix approach like "_" or "priv". Pharo has a unified property API so one can annotate both: methods and classes (unfortunately not yet serialized into Tonel). It could be used to depict a scope or other: Â Â Â Â MyClass propertyAt: #scope put: #private. The rest is a tool issue for calls, autocompletion, check for local/private/protected senders, ... Regards T. Am 23.08.2021 um 14:05 schrieb Esteban Maringolo: > If something, I'd rather have _ as a prefix indicating a private > method, very much like Dart does. > But why use a "syntax" trick when it could be an attribute of the > CompiledMethod itself? > > As for many private methods being a code smell... it could be, but it > depends, until you find the right abstractions you might want to keep > private all the stuff that is causing the smell :-) > > > > > Esteban A. Maringolo > > On Mon, Aug 23, 2021 at 8:06 AM Tim Mackinnon <tim(a)testit.works> wrote: >> As many have described, Iâve seen this work reasonably well too - while Iâve seen the pvt prefix convention, Iâve also seen _name used to - which I felt was marginally better (it also means private methods get grouped at the top of the âall listâ and not alphabetically in the middleâish (but itâs a minor thing as browser tools can filter appropriately anyway, and to be honest, showing private at the bottom or in a separate place is better). >> >> It is worth saying however - that lots if pvt methods can be a code smell - it may be better to move them to a separate âpolicy objectâ and then focus on better delegation options - which I believe is where Pharo is heading with variables as first class objects (and hopefully Marcus will cover in the U.K. Smalltalk Meetup this week). >> >> Too often we end up up with lots of sub classing and overriding and privatising - when there is a new object that could group all this stuff and the methods can be public in that delegate - while the delegate itself is a âprivateâ object. >> >> I think this should be explored more actually. >> >> Tim >> >>> On 20 Aug 2021, at 11:19, Richard O'Keefe <raoknz(a)gmail.com> wrote: >>> >>> ï»¿One of the claimed benefits of object-oriented programming is ENCAPSULATION. >>> The idea is that one of the ways a language helps you is by making some errors >>> difficult or impossible to express. >>> One of the things you need to understand an object is its INVARIANT. >>> For example, astc's SortedCollection includes >>> >>> methods for: 'checking' >>> invariant >>> ^(opposite isNil or: [ >>> opposite isKindOf: DyadicBlock]) and: [ >>> super invariant and: [ >>> (sortBlock >>> ifNil: [(offset + 2 to: offset + size) allSatisfy: [:i | >>> (array at: i-1) <= (array at: i)]] >>> ifNotNil: [(sortBlock respondsTo: #value:value:) and: [ >>> [(offset + 2 to: offset + size) allSatisfy: [:i | >>> (sortBlock value: (array at: i-1) >>> value: (array at: i))]]]])]] >>> >>> Private methods are allowed to break the invariant. >>> Public methods are not. >>> >>> For example, consider reversing a SortedCollection. >>> Part of this changes the order of the elements, and can be >>> shared with OrderedCollection. Part of it swaps the arguments >>> of the sortBlock, and cannot be shared. >>> >>> methods for: 'rearranging' >>> pvtPrereverse >>> |t| >>> opposite >>> ifNil: [ >>> sortBlock ifNil: [sortBlock := Magnitude defaultSortBlock]. >>> t := sortBlock. >>> opposite := sortBlock. >>> sortBlock := [:x :y | t value: y value: x]] >>> ifNotNil: [ >>> t := sortBlock. >>> sortBlock := opposite. >>> opposite := t]. >>> >>> If this method could be called from "outside", it would certainly break >>> the invariant and leave the object in an unusable state. >>> >>> Now a style rule doesn't *quite* prevent this method being called by >>> another object. >>> It is necessary to make sure that #perform: and friends cannot break >>> encapsulation >>> either, and this astc does by simply not creating Selector objects for >>> private methods. >>> >>> Yes, it is a small increase in the complexity of the language, however >>> - you are not forced to write private methods >>> - if you run code that uses the pvt* convention in a Smalltalk that does >>> not use that convention, it works, it's just not safe any longer >>> - it is not an arbitrary addition to the language, it is a restriction that >>> makes programming *easier*. >>> >>> Let's look at one additional example. >>> Behavior>> >>> new >>> ^ self basicNew initialize >>> >>> This means that *any* object can forcibly reinitialize *any* object it can >>> reach at *any* time. In astc, it's >>> >>> new >>> "other checks" >>> ^self pvtNew pvtPostNew >>> >>> and an object cannot be reinitialised against its will. >>> >>> There is a long standing tradition of "program for the typical case and trust >>> the omniscient programmer to know what will probably work and what won't" >>> in Smalltalk. This is why in many Smalltalks >>> aCollection addAll: aCollection >>> or >>> aCollection removeAll: aCollection >>> can go insane for some common collections. And one *DOES* get away >>> with it most of the time. It's typically when someone else triest to use your >>> code and doesn't know the assumptions you didn't bother to write down >>> that things go wrong. It's obvious that Pharo has got to where it >>> amazingly well is without the "bondage and discipline" of, say, Ada or >>> Agda. But there is a *reason* why Pharo has lint checking on by default. >>> >>>> On Fri, 20 Aug 2021 at 00:59, Jesus Mari Aguirre <jmariaguirre(a)gmail.com> wrote: >>>> >>>> Please keep Pharo simple, why do you need private methods...you can include then in a protocol named private...other language have it...yes...next addition will be namespaces...other...I don't know...at last we have Java >>>> >>>> El jue., 19 ago. 2021 9:00, Richard O'Keefe <raoknz(a)gmail.com> escribiÃ³: >>>>> Many years ago there was a proposal in the Squeak mailing list about enforcing >>>>> a naming convention, "pvt", I implemented that in my Smalltalk system. The >>>>> compiler enforces the rule that pvt.[A-Z].* message can only be sent to >>>>> (self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)? >>>>> in a class method or >>>>> (self|super) ((class (new|new: n)|pvtSpeciesNew: n|pvtClone)? >>>>> in an instance method. >>>>> There are currently >>>>> 9412 public selectors >>>>> 793 pvt* selectors and >>>>> 23 private* selectors, >>>>> where the last group is methods that I *want* to be private in some sense but >>>>> cannot do with this machinery. (For example, calling a "private" method on >>>>> another object known to be of the same class.) >>>>> >>>>> I think the evidence shows that this works well enough to be useful, even if it >>>>> isn't quite as expressive as I'd like. And what *that* means is that >>>>> this can be >>>>> done with a style check, using the machinery Pharo already has for style checks. >>>>> >>>>> >>>>> >>>>> On Wed, 18 Aug 2021 at 08:14, Craig Johnson <craig(a)hivemind.net> wrote: >>>>>> Hi All, >>>>>> >>>>>> >>>>>> Just a newb off-the-wall question. >>>>>> >>>>>> Is there any good reason why we can't create a true private method in a >>>>>> Pharo class by putting that method inside an instance or class variable >>>>>> as a lambda (block). >>>>>> >>>>>> >>>>>> This would reduce one of my biggest bugbears with Pharo, namely the >>>>>> pollution of the global namespace with every single message name in the >>>>>> entire system. >>>>>> >>>>>> >>>>>> >>>>>> Craig

Aug. 23, 2021

Re: Private Methods

by Esteban Maringolo

If something, I'd rather have _ as a prefix indicating a private method, very much like Dart does. But why use a "syntax" trick when it could be an attribute of the CompiledMethod itself? As for many private methods being a code smell... it could be, but it depends, until you find the right abstractions you might want to keep private all the stuff that is causing the smell :-) Esteban A. Maringolo On Mon, Aug 23, 2021 at 8:06 AM Tim Mackinnon <tim(a)testit.works> wrote: > > As many have described, Iâve seen this work reasonably well too - while Iâve seen the pvt prefix convention, Iâve also seen _name used to - which I felt was marginally better (it also means private methods get grouped at the top of the âall listâ and not alphabetically in the middleâish (but itâs a minor thing as browser tools can filter appropriately anyway, and to be honest, showing private at the bottom or in a separate place is better). > > It is worth saying however - that lots if pvt methods can be a code smell - it may be better to move them to a separate âpolicy objectâ and then focus on better delegation options - which I believe is where Pharo is heading with variables as first class objects (and hopefully Marcus will cover in the U.K. Smalltalk Meetup this week). > > Too often we end up up with lots of sub classing and overriding and privatising - when there is a new object that could group all this stuff and the methods can be public in that delegate - while the delegate itself is a âprivateâ object. > > I think this should be explored more actually. > > Tim > > > On 20 Aug 2021, at 11:19, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > ï»¿One of the claimed benefits of object-oriented programming is ENCAPSULATION. > > The idea is that one of the ways a language helps you is by making some errors > > difficult or impossible to express. > > One of the things you need to understand an object is its INVARIANT. > > For example, astc's SortedCollection includes > > > > methods for: 'checking' > > invariant > > ^(opposite isNil or: [ > > opposite isKindOf: DyadicBlock]) and: [ > > super invariant and: [ > > (sortBlock > > ifNil: [(offset + 2 to: offset + size) allSatisfy: [:i | > > (array at: i-1) <= (array at: i)]] > > ifNotNil: [(sortBlock respondsTo: #value:value:) and: [ > > [(offset + 2 to: offset + size) allSatisfy: [:i | > > (sortBlock value: (array at: i-1) > > value: (array at: i))]]]])]] > > > > Private methods are allowed to break the invariant. > > Public methods are not. > > > > For example, consider reversing a SortedCollection. > > Part of this changes the order of the elements, and can be > > shared with OrderedCollection. Part of it swaps the arguments > > of the sortBlock, and cannot be shared. > > > > methods for: 'rearranging' > > pvtPrereverse > > |t| > > opposite > > ifNil: [ > > sortBlock ifNil: [sortBlock := Magnitude defaultSortBlock]. > > t := sortBlock. > > opposite := sortBlock. > > sortBlock := [:x :y | t value: y value: x]] > > ifNotNil: [ > > t := sortBlock. > > sortBlock := opposite. > > opposite := t]. > > > > If this method could be called from "outside", it would certainly break > > the invariant and leave the object in an unusable state. > > > > Now a style rule doesn't *quite* prevent this method being called by > > another object. > > It is necessary to make sure that #perform: and friends cannot break > > encapsulation > > either, and this astc does by simply not creating Selector objects for > > private methods. > > > > Yes, it is a small increase in the complexity of the language, however > > - you are not forced to write private methods > > - if you run code that uses the pvt* convention in a Smalltalk that does > > not use that convention, it works, it's just not safe any longer > > - it is not an arbitrary addition to the language, it is a restriction that > > makes programming *easier*. > > > > Let's look at one additional example. > > Behavior>> > > new > > ^ self basicNew initialize > > > > This means that *any* object can forcibly reinitialize *any* object it can > > reach at *any* time. In astc, it's > > > > new > > "other checks" > > ^self pvtNew pvtPostNew > > > > and an object cannot be reinitialised against its will. > > > > There is a long standing tradition of "program for the typical case and trust > > the omniscient programmer to know what will probably work and what won't" > > in Smalltalk. This is why in many Smalltalks > > aCollection addAll: aCollection > > or > > aCollection removeAll: aCollection > > can go insane for some common collections. And one *DOES* get away > > with it most of the time. It's typically when someone else triest to use your > > code and doesn't know the assumptions you didn't bother to write down > > that things go wrong. It's obvious that Pharo has got to where it > > amazingly well is without the "bondage and discipline" of, say, Ada or > > Agda. But there is a *reason* why Pharo has lint checking on by default. > > > >> On Fri, 20 Aug 2021 at 00:59, Jesus Mari Aguirre <jmariaguirre(a)gmail.com> wrote: > >> > >> Please keep Pharo simple, why do you need private methods...you can include then in a protocol named private...other language have it...yes...next addition will be namespaces...other...I don't know...at last we have Java > >> > >> El jue., 19 ago. 2021 9:00, Richard O'Keefe <raoknz(a)gmail.com> escribiÃ³: > >>> > >>> Many years ago there was a proposal in the Squeak mailing list about enforcing > >>> a naming convention, "pvt", I implemented that in my Smalltalk system. The > >>> compiler enforces the rule that pvt.[A-Z].* message can only be sent to > >>> (self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)? > >>> in a class method or > >>> (self|super) ((class (new|new: n)|pvtSpeciesNew: n|pvtClone)? > >>> in an instance method. > >>> There are currently > >>> 9412 public selectors > >>> 793 pvt* selectors and > >>> 23 private* selectors, > >>> where the last group is methods that I *want* to be private in some sense but > >>> cannot do with this machinery. (For example, calling a "private" method on > >>> another object known to be of the same class.) > >>> > >>> I think the evidence shows that this works well enough to be useful, even if it > >>> isn't quite as expressive as I'd like. And what *that* means is that > >>> this can be > >>> done with a style check, using the machinery Pharo already has for style checks. > >>> > >>> > >>> > >>> On Wed, 18 Aug 2021 at 08:14, Craig Johnson <craig(a)hivemind.net> wrote: > >>>> > >>>> Hi All, > >>>> > >>>> > >>>> Just a newb off-the-wall question. > >>>> > >>>> Is there any good reason why we can't create a true private method in a > >>>> Pharo class by putting that method inside an instance or class variable > >>>> as a lambda (block). > >>>> > >>>> > >>>> This would reduce one of my biggest bugbears with Pharo, namely the > >>>> pollution of the global namespace with every single message name in the > >>>> entire system. > >>>> > >>>> > >>>> > >>>> Craig

Aug. 23, 2021

Re: Private Methods

by Tim Mackinnon

As many have described, Iâve seen this work reasonably well too - while Iâve seen the pvt prefix convention, Iâve also seen _name used to - which I felt was marginally better (it also means private methods get grouped at the top of the âall listâ and not alphabetically in the middleâish (but itâs a minor thing as browser tools can filter appropriately anyway, and to be honest, showing private at the bottom or in a separate place is better). It is worth saying however - that lots if pvt methods can be a code smell - it may be better to move them to a separate âpolicy objectâ and then focus on better delegation options - which I believe is where Pharo is heading with variables as first class objects (and hopefully Marcus will cover in the U.K. Smalltalk Meetup this week). Too often we end up up with lots of sub classing and overriding and privatising - when there is a new object that could group all this stuff and the methods can be public in that delegate - while the delegate itself is a âprivateâ object. I think this should be explored more actually. Tim > On 20 Aug 2021, at 11:19, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > ï»¿One of the claimed benefits of object-oriented programming is ENCAPSULATION. > The idea is that one of the ways a language helps you is by making some errors > difficult or impossible to express. > One of the things you need to understand an object is its INVARIANT. > For example, astc's SortedCollection includes > > methods for: 'checking' > invariant > ^(opposite isNil or: [ > opposite isKindOf: DyadicBlock]) and: [ > super invariant and: [ > (sortBlock > ifNil: [(offset + 2 to: offset + size) allSatisfy: [:i | > (array at: i-1) <= (array at: i)]] > ifNotNil: [(sortBlock respondsTo: #value:value:) and: [ > [(offset + 2 to: offset + size) allSatisfy: [:i | > (sortBlock value: (array at: i-1) > value: (array at: i))]]]])]] > > Private methods are allowed to break the invariant. > Public methods are not. > > For example, consider reversing a SortedCollection. > Part of this changes the order of the elements, and can be > shared with OrderedCollection. Part of it swaps the arguments > of the sortBlock, and cannot be shared. > > methods for: 'rearranging' > pvtPrereverse > |t| > opposite > ifNil: [ > sortBlock ifNil: [sortBlock := Magnitude defaultSortBlock]. > t := sortBlock. > opposite := sortBlock. > sortBlock := [:x :y | t value: y value: x]] > ifNotNil: [ > t := sortBlock. > sortBlock := opposite. > opposite := t]. > > If this method could be called from "outside", it would certainly break > the invariant and leave the object in an unusable state. > > Now a style rule doesn't *quite* prevent this method being called by > another object. > It is necessary to make sure that #perform: and friends cannot break > encapsulation > either, and this astc does by simply not creating Selector objects for > private methods. > > Yes, it is a small increase in the complexity of the language, however > - you are not forced to write private methods > - if you run code that uses the pvt* convention in a Smalltalk that does > not use that convention, it works, it's just not safe any longer > - it is not an arbitrary addition to the language, it is a restriction that > makes programming *easier*. > > Let's look at one additional example. > Behavior>> > new > ^ self basicNew initialize > > This means that *any* object can forcibly reinitialize *any* object it can > reach at *any* time. In astc, it's > > new > "other checks" > ^self pvtNew pvtPostNew > > and an object cannot be reinitialised against its will. > > There is a long standing tradition of "program for the typical case and trust > the omniscient programmer to know what will probably work and what won't" > in Smalltalk. This is why in many Smalltalks > aCollection addAll: aCollection > or > aCollection removeAll: aCollection > can go insane for some common collections. And one *DOES* get away > with it most of the time. It's typically when someone else triest to use your > code and doesn't know the assumptions you didn't bother to write down > that things go wrong. It's obvious that Pharo has got to where it > amazingly well is without the "bondage and discipline" of, say, Ada or > Agda. But there is a *reason* why Pharo has lint checking on by default. > >> On Fri, 20 Aug 2021 at 00:59, Jesus Mari Aguirre <jmariaguirre(a)gmail.com> wrote: >> >> Please keep Pharo simple, why do you need private methods...you can include then in a protocol named private...other language have it...yes...next addition will be namespaces...other...I don't know...at last we have Java >> >> El jue., 19 ago. 2021 9:00, Richard O'Keefe <raoknz(a)gmail.com> escribiÃ³: >>> >>> Many years ago there was a proposal in the Squeak mailing list about enforcing >>> a naming convention, "pvt", I implemented that in my Smalltalk system. The >>> compiler enforces the rule that pvt.[A-Z].* message can only be sent to >>> (self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)? >>> in a class method or >>> (self|super) ((class (new|new: n)|pvtSpeciesNew: n|pvtClone)? >>> in an instance method. >>> There are currently >>> 9412 public selectors >>> 793 pvt* selectors and >>> 23 private* selectors, >>> where the last group is methods that I *want* to be private in some sense but >>> cannot do with this machinery. (For example, calling a "private" method on >>> another object known to be of the same class.) >>> >>> I think the evidence shows that this works well enough to be useful, even if it >>> isn't quite as expressive as I'd like. And what *that* means is that >>> this can be >>> done with a style check, using the machinery Pharo already has for style checks. >>> >>> >>> >>> On Wed, 18 Aug 2021 at 08:14, Craig Johnson <craig(a)hivemind.net> wrote: >>>> >>>> Hi All, >>>> >>>> >>>> Just a newb off-the-wall question. >>>> >>>> Is there any good reason why we can't create a true private method in a >>>> Pharo class by putting that method inside an instance or class variable >>>> as a lambda (block). >>>> >>>> >>>> This would reduce one of my biggest bugbears with Pharo, namely the >>>> pollution of the global namespace with every single message name in the >>>> entire system. >>>> >>>> >>>> >>>> Craig

Aug. 23, 2021

[ANN] Stargate v6.1.1 [v6.1.1] released!

by Buenos Aires Smalltalk

Aug. 20, 2021

Re: Private Methods

by Richard O'Keefe

One of the claimed benefits of object-oriented programming is ENCAPSULATION. The idea is that one of the ways a language helps you is by making some errors difficult or impossible to express. One of the things you need to understand an object is its INVARIANT. For example, astc's SortedCollection includes methods for: 'checking' invariant ^(opposite isNil or: [ opposite isKindOf: DyadicBlock]) and: [ super invariant and: [ (sortBlock ifNil: [(offset + 2 to: offset + size) allSatisfy: [:i | (array at: i-1) <= (array at: i)]] ifNotNil: [(sortBlock respondsTo: #value:value:) and: [ [(offset + 2 to: offset + size) allSatisfy: [:i | (sortBlock value: (array at: i-1) value: (array at: i))]]]])]] Private methods are allowed to break the invariant. Public methods are not. For example, consider reversing a SortedCollection. Part of this changes the order of the elements, and can be shared with OrderedCollection. Part of it swaps the arguments of the sortBlock, and cannot be shared. methods for: 'rearranging' pvtPrereverse |t| opposite ifNil: [ sortBlock ifNil: [sortBlock := Magnitude defaultSortBlock]. t := sortBlock. opposite := sortBlock. sortBlock := [:x :y | t value: y value: x]] ifNotNil: [ t := sortBlock. sortBlock := opposite. opposite := t]. If this method could be called from "outside", it would certainly break the invariant and leave the object in an unusable state. Now a style rule doesn't *quite* prevent this method being called by another object. It is necessary to make sure that #perform: and friends cannot break encapsulation either, and this astc does by simply not creating Selector objects for private methods. Yes, it is a small increase in the complexity of the language, however - you are not forced to write private methods - if you run code that uses the pvt* convention in a Smalltalk that does not use that convention, it works, it's just not safe any longer - it is not an arbitrary addition to the language, it is a restriction that makes programming *easier*. Let's look at one additional example. Behavior>> new ^ self basicNew initialize This means that *any* object can forcibly reinitialize *any* object it can reach at *any* time. In astc, it's new "other checks" ^self pvtNew pvtPostNew and an object cannot be reinitialised against its will. There is a long standing tradition of "program for the typical case and trust the omniscient programmer to know what will probably work and what won't" in Smalltalk. This is why in many Smalltalks aCollection addAll: aCollection or aCollection removeAll: aCollection can go insane for some common collections. And one *DOES* get away with it most of the time. It's typically when someone else triest to use your code and doesn't know the assumptions you didn't bother to write down that things go wrong. It's obvious that Pharo has got to where it amazingly well is without the "bondage and discipline" of, say, Ada or Agda. But there is a *reason* why Pharo has lint checking on by default. On Fri, 20 Aug 2021 at 00:59, Jesus Mari Aguirre <jmariaguirre(a)gmail.com> wrote: > > Please keep Pharo simple, why do you need private methods...you can include then in a protocol named private...other language have it...yes...next addition will be namespaces...other...I don't know...at last we have Java > > El jue., 19 ago. 2021 9:00, Richard O'Keefe <raoknz(a)gmail.com> escribiÃ³: >> >> Many years ago there was a proposal in the Squeak mailing list about enforcing >> a naming convention, "pvt", I implemented that in my Smalltalk system. The >> compiler enforces the rule that pvt.[A-Z].* message can only be sent to >> (self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)? >> in a class method or >> (self|super) ((class (new|new: n)|pvtSpeciesNew: n|pvtClone)? >> in an instance method. >> There are currently >> 9412 public selectors >> 793 pvt* selectors and >> 23 private* selectors, >> where the last group is methods that I *want* to be private in some sense but >> cannot do with this machinery. (For example, calling a "private" method on >> another object known to be of the same class.) >> >> I think the evidence shows that this works well enough to be useful, even if it >> isn't quite as expressive as I'd like. And what *that* means is that >> this can be >> done with a style check, using the machinery Pharo already has for style checks. >> >> >> >> On Wed, 18 Aug 2021 at 08:14, Craig Johnson <craig(a)hivemind.net> wrote: >> > >> > Hi All, >> > >> > >> > Just a newb off-the-wall question. >> > >> > Is there any good reason why we can't create a true private method in a >> > Pharo class by putting that method inside an instance or class variable >> > as a lambda (block). >> > >> > >> > This would reduce one of my biggest bugbears with Pharo, namely the >> > pollution of the global namespace with every single message name in the >> > entire system. >> > >> > >> > >> > Craig

Aug. 20, 2021

Re: Private Methods

by Esteban Maringolo

Public/Private is not just a category, it is also a declaration of what is the interface of the object. As I said, it's not critical, but I've been working with and without a "native" private method, and I prefer working with them. Namespacing is a different animal, and not as simple to implement as private methods. Best regards, Esteban A. Maringolo On Thu, Aug 19, 2021 at 9:59 AM Jesus Mari Aguirre <jmariaguirre(a)gmail.com> wrote: > > Please keep Pharo simple, why do you need private methods...you can include then in a protocol named private...other language have it...yes...next addition will be namespaces...other...I don't know...at last we have Java > > El jue., 19 ago. 2021 9:00, Richard O'Keefe <raoknz(a)gmail.com> escribiÃ³: >> >> Many years ago there was a proposal in the Squeak mailing list about enforcing >> a naming convention, "pvt", I implemented that in my Smalltalk system. The >> compiler enforces the rule that pvt.[A-Z].* message can only be sent to >> (self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)? >> in a class method or >> (self|super) ((class (new|new: n)|pvtSpeciesNew: n|pvtClone)? >> in an instance method. >> There are currently >> 9412 public selectors >> 793 pvt* selectors and >> 23 private* selectors, >> where the last group is methods that I *want* to be private in some sense but >> cannot do with this machinery. (For example, calling a "private" method on >> another object known to be of the same class.) >> >> I think the evidence shows that this works well enough to be useful, even if it >> isn't quite as expressive as I'd like. And what *that* means is that >> this can be >> done with a style check, using the machinery Pharo already has for style checks. >> >> >> >> On Wed, 18 Aug 2021 at 08:14, Craig Johnson <craig(a)hivemind.net> wrote: >> > >> > Hi All, >> > >> > >> > Just a newb off-the-wall question. >> > >> > Is there any good reason why we can't create a true private method in a >> > Pharo class by putting that method inside an instance or class variable >> > as a lambda (block). >> > >> > >> > This would reduce one of my biggest bugbears with Pharo, namely the >> > pollution of the global namespace with every single message name in the >> > entire system. >> > >> > >> > >> > Craig

Aug. 19, 2021

Re: Private Methods

by Jesus Mari Aguirre

Please keep Pharo simple, why do you need private methods...you can include then in a protocol named private...other language have it...yes...next addition will be namespaces...other...I don't know...at last we have Java El jue., 19 ago. 2021 9:00, Richard O'Keefe <raoknz(a)gmail.com> escribiÃ³: > Many years ago there was a proposal in the Squeak mailing list about > enforcing > a naming convention, "pvt", I implemented that in my Smalltalk system. > The > compiler enforces the rule that pvt.[A-Z].* message can only be sent to > (self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)? > in a class method or > (self|super) ((class (new|new: n)|pvtSpeciesNew: n|pvtClone)? > in an instance method. > There are currently > 9412 public selectors > 793 pvt* selectors and > 23 private* selectors, > where the last group is methods that I *want* to be private in some sense > but > cannot do with this machinery. (For example, calling a "private" method on > another object known to be of the same class.) > > I think the evidence shows that this works well enough to be useful, even > if it > isn't quite as expressive as I'd like. And what *that* means is that > this can be > done with a style check, using the machinery Pharo already has for style > checks. > > > > On Wed, 18 Aug 2021 at 08:14, Craig Johnson <craig(a)hivemind.net> wrote: > > > > Hi All, > > > > > > Just a newb off-the-wall question. > > > > Is there any good reason why we can't create a true private method in a > > Pharo class by putting that method inside an instance or class variable > > as a lambda (block). > > > > > > This would reduce one of my biggest bugbears with Pharo, namely the > > pollution of the global namespace with every single message name in the > > entire system. > > > > > > > > Craig >

Aug. 19, 2021

Re: Private Methods

by Richard O'Keefe

Many years ago there was a proposal in the Squeak mailing list about enforcing a naming convention, "pvt", I implemented that in my Smalltalk system. The compiler enforces the rule that pvt.[A-Z].* message can only be sent to (self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)? in a class method or (self|super) ((class (new|new: n)|pvtSpeciesNew: n|pvtClone)? in an instance method. There are currently 9412 public selectors 793 pvt* selectors and 23 private* selectors, where the last group is methods that I *want* to be private in some sense but cannot do with this machinery. (For example, calling a "private" method on another object known to be of the same class.) I think the evidence shows that this works well enough to be useful, even if it isn't quite as expressive as I'd like. And what *that* means is that this can be done with a style check, using the machinery Pharo already has for style checks. On Wed, 18 Aug 2021 at 08:14, Craig Johnson <craig(a)hivemind.net> wrote: > > Hi All, > > > Just a newb off-the-wall question. > > Is there any good reason why we can't create a true private method in a > Pharo class by putting that method inside an instance or class variable > as a lambda (block). > > > This would reduce one of my biggest bugbears with Pharo, namely the > pollution of the global namespace with every single message name in the > entire system. > > > > Craig

Aug. 19, 2021

Re: Private Methods

by David Pennington

I found this useful when creating commercial frameworks for VAST. For instance, in the printing framework, I used the idea of a turtle (from turtlegraphics) to create pages. All the turtle commands - turn(50) etc - were public but the code that actually created the printing code was all private. Hence purchases knew not to touch the private methods. David > On 18 Aug 2021, at 14:31, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Hi Noury, > > In Dolphin Smalltalk and in IBM/VA Smalltalk, methods can be private, > it's a special attribute of the CompiledMethod, so the visibility > doesn't depend on a category name convention, and you can have both > public and private methods sharing a single category. I used that > attribute extensively in the previously described dialects, and it led > to good method categorization, in the case of Dolphin, it had the nice > thing of adding "Private - ..." to the method comment when you toggle > a method as private. > > I'm fine with the current state of everything being public, but if we > were to have that public/private distinction that would be the > simplest solution, having a <private> pragma could also work, but I > think that in terms of performance it could impact the lookup. I don't > know, however, if that is what the original request was after. > > Best regards, > > Esteban A. Maringolo > > On Wed, Aug 18, 2021 at 9:47 AM Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: >> >> Hi Esteban, >> >> Which first "class attribute" are you referring to? Is it a pragma? Can you provide an example please ? >> >> Thanx >> Noury >> >> On Aug 17 2021, at 10:31 pm, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> I don't understand the request? >> >> Wouldn't tagging methods as private (as a first class attribute, and >> not only its category) be enough? >> >> What you ask for seems to be a splitted method dictionary of some sort. >> >> Having first class private methods would save you from autocomplete >> selector "pollution" of private methods. >> >> Regards! >> >> Esteban A. Maringolo >> >> On Tue, Aug 17, 2021 at 5:14 PM Craig Johnson <craig(a)hivemind.net> wrote: >>> >>> Hi All, >>> >>> >>> Just a newb off-the-wall question. >>> >>> Is there any good reason why we can't create a true private method in a >>> Pharo class by putting that method inside an instance or class variable >>> as a lambda (block). >>> >>> >>> This would reduce one of my biggest bugbears with Pharo, namely the >>> pollution of the global namespace with every single message name in the >>> entire system. >>> >>> >>> >>> Craig

Aug. 18, 2021

Re: Private Methods

by Gabriel Cotelli

As Esteban pointed out there are some dialects with proper support for that. But the semantics is the same as in Pharo, you can still send these messages. It is more a warning to the programmer, and the browser shows you these methods with a particular icon or has tabs so you can easily filter out the methods marked as private. A least in VA is done by attaching some metadata to the methods and not changing its source code. On Wed, Aug 18, 2021 at 10:32 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > Hi Noury, > > In Dolphin Smalltalk and in IBM/VA Smalltalk, methods can be private, > it's a special attribute of the CompiledMethod, so the visibility > doesn't depend on a category name convention, and you can have both > public and private methods sharing a single category. I used that > attribute extensively in the previously described dialects, and it led > to good method categorization, in the case of Dolphin, it had the nice > thing of adding "Private - ..." to the method comment when you toggle > a method as private. > > I'm fine with the current state of everything being public, but if we > were to have that public/private distinction that would be the > simplest solution, having a <private> pragma could also work, but I > think that in terms of performance it could impact the lookup. I don't > know, however, if that is what the original request was after. > > Best regards, > > Esteban A. Maringolo > > On Wed, Aug 18, 2021 at 9:47 AM Noury Bouraqadi <bouraqadi(a)gmail.com> > wrote: > > > > Hi Esteban, > > > > Which first "class attribute" are you referring to? Is it a pragma? Can > you provide an example please ? > > > > Thanx > > Noury > > > > On Aug 17 2021, at 10:31 pm, Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > > > > I don't understand the request? > > > > Wouldn't tagging methods as private (as a first class attribute, and > > not only its category) be enough? > > > > What you ask for seems to be a splitted method dictionary of some sort. > > > > Having first class private methods would save you from autocomplete > > selector "pollution" of private methods. > > > > Regards! > > > > Esteban A. Maringolo > > > > On Tue, Aug 17, 2021 at 5:14 PM Craig Johnson <craig(a)hivemind.net> > wrote: > > > > > > Hi All, > > > > > > > > > Just a newb off-the-wall question. > > > > > > Is there any good reason why we can't create a true private method in a > > > Pharo class by putting that method inside an instance or class variable > > > as a lambda (block). > > > > > > > > > This would reduce one of my biggest bugbears with Pharo, namely the > > > pollution of the global namespace with every single message name in the > > > entire system. > > > > > > > > > > > > Craig >

Aug. 18, 2021

Re: Private Methods

by Esteban Maringolo

Hi Noury, In Dolphin Smalltalk and in IBM/VA Smalltalk, methods can be private, it's a special attribute of the CompiledMethod, so the visibility doesn't depend on a category name convention, and you can have both public and private methods sharing a single category. I used that attribute extensively in the previously described dialects, and it led to good method categorization, in the case of Dolphin, it had the nice thing of adding "Private - ..." to the method comment when you toggle a method as private. I'm fine with the current state of everything being public, but if we were to have that public/private distinction that would be the simplest solution, having a <private> pragma could also work, but I think that in terms of performance it could impact the lookup. I don't know, however, if that is what the original request was after. Best regards, Esteban A. Maringolo On Wed, Aug 18, 2021 at 9:47 AM Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > Hi Esteban, > > Which first "class attribute" are you referring to? Is it a pragma? Can you provide an example please ? > > Thanx > Noury > > On Aug 17 2021, at 10:31 pm, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > I don't understand the request? > > Wouldn't tagging methods as private (as a first class attribute, and > not only its category) be enough? > > What you ask for seems to be a splitted method dictionary of some sort. > > Having first class private methods would save you from autocomplete > selector "pollution" of private methods. > > Regards! > > Esteban A. Maringolo > > On Tue, Aug 17, 2021 at 5:14 PM Craig Johnson <craig(a)hivemind.net> wrote: > > > > Hi All, > > > > > > Just a newb off-the-wall question. > > > > Is there any good reason why we can't create a true private method in a > > Pharo class by putting that method inside an instance or class variable > > as a lambda (block). > > > > > > This would reduce one of my biggest bugbears with Pharo, namely the > > pollution of the global namespace with every single message name in the > > entire system. > > > > > > > > Craig

Aug. 18, 2021

Re: Private Methods

by Noury Bouraqadi

Hi Esteban, Which first "class attribute" are you referring to? Is it a pragma? Can you provide an example please ? Thanx Noury On Aug 17 2021, at 10:31 pm, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > I don't understand the request? > > Wouldn't tagging methods as private (as a first class attribute, and > not only its category) be enough? > > What you ask for seems to be a splitted method dictionary of some sort. > Having first class private methods would save you from autocomplete > selector "pollution" of private methods. > > Regards! > Esteban A. Maringolo > On Tue, Aug 17, 2021 at 5:14 PM Craig Johnson <craig(a)hivemind.net> wrote: > > > > Hi All, > > > > > > Just a newb off-the-wall question. > > > > Is there any good reason why we can't create a true private method in a > > Pharo class by putting that method inside an instance or class variable > > as a lambda (block). > > > > > > This would reduce one of my biggest bugbears with Pharo, namely the > > pollution of the global namespace with every single message name in the > > entire system. > > > > > > > > Craig >

Aug. 18, 2021

Re: Private Methods

by Esteban Maringolo

I don't understand the request? Wouldn't tagging methods as private (as a first class attribute, and not only its category) be enough? What you ask for seems to be a splitted method dictionary of some sort. Having first class private methods would save you from autocomplete selector "pollution" of private methods. Regards! Esteban A. Maringolo On Tue, Aug 17, 2021 at 5:14 PM Craig Johnson <craig(a)hivemind.net> wrote: > > Hi All, > > > Just a newb off-the-wall question. > > Is there any good reason why we can't create a true private method in a > Pharo class by putting that method inside an instance or class variable > as a lambda (block). > > > This would reduce one of my biggest bugbears with Pharo, namely the > pollution of the global namespace with every single message name in the > entire system. > > > > Craig

Aug. 17, 2021

Private Methods

by Craig Johnson

Hi All, Just a newb off-the-wall question. Is there any good reason why we can't create a true private method in a Pharo class by putting that method inside an instance or class variable as a lambda (block). This would reduce one of my biggest bugbears with Pharo, namely the pollution of the global namespace with every single message name in the entire system. Craig

Aug. 17, 2021

UK Smalltalk User Group Meeting - Wednesday, August 25th

by Giovanni Corriga

The next meeting of the UK Smalltalk User Group will be on Wednesday, August 25th. Marcus Denker will talk about Variables in Pharo. We like to say that âEverything is an Objectâ in Smalltalk. This is true in many cases: Classes, methods, even the execution stack are reflectively available as objects. This talk shows how this idea can be extended to Variables and how Pharo implements first-class Variables for Globals, instance Variables, Class Variables, and even temporary variables. This presentation explores the Variable hierarchy, shows how variables simplify the compiler and how the reflective API provided by variables is used by the debugger. In a hands-on tutorial, we extend the language by defining new kinds of Variables. Marcus ( https://marcusdenker.de/ ) is a permanent researcher at INRIA Lille - Nord Europe ( http://www.inria.fr/lille/ ). Before, he was a postdoc at the PLEIAD lab/DCC University of Chile and the Software Composition Group, University of Bern. His research focuses on reflection and meta-programming for dynamic languages. Marcus Denker received a PhD in Computer Science from the University of Bern/Switzerland in 2008 and a Dipl.-Inform. (MSc) from the University of Karlsruhe/Germany in 2004. He co-founded Zweidenker GmbH ( https://zweidenker.de/ ) in 2009. 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/cbklbrycclbhc/ ) to receive the meeting details. Donât forget to bring your laptop and drinks!

Aug. 16, 2021

Re: File-in Issue - Pharo 9

by David Pennington

Aug. 16, 2021

Re: Exercism v3 problems

by Roelof Wobben

I understand. Hopefully someone can and is willing to help me and we can give the user the experience he/she needs. I think that what you have said earlier, could be very in hand. That Syunit could be working standalone. > Op 15 augustus 2021 om 23:16 schreef "stephane.ducasse(a)free.fr" <stephane.ducasse(a)free.fr>: > > > Thanks for the info. > > I read a bit the âspecâ > I do not really get the test method cannot be passed? Anywayâ¦. > > > This is the body of the command that is being tested. For example, the following Ruby test: > > def test_duplicate_items_uniqs_list > cart = ShoppingCart.new > cart.add(:STARIC) > cart.add(:MEDNEW) > cart.add(:MEDNEW) > assert_equal 'Newspaper, Rice', cart.items_list > end > should return a test_code value of: > > "cart = ShoppingCart.new > cart.add(:STARIC) > cart.add(:MEDNEW) > cart.add(:MEDNEW) > assert_equal 'Newspaper, Rice', cart.items_list" > Looking at the other implementation can help. > > https://github.com/exercism?q=-test-runner > > Now my plate is more than full. So I cannot really help because I have too many things unfinished and that should be done. > > S > > > > On 15 Aug 2021, at 21:02, Roelof Wobben <r.wobben(a)home.nl> wrote: > > > > Yep, > > > > The spec and other information can be found here : https://github.com/exercism/docs/blob/main/building/tooling/test-runners/in… <https://github.com/exercism/docs/blob/main/building/tooling/test-runners/in…> > > > > I hoping we can get number 2 or 3 working. > > > > Roelof > > > > > > > > Op 15-8-2021 om 15:15 schreef stephane.ducasse(a)free.fr <mailto:stephane.ducasse@free.fr>: > >> > >>> Yes, > >>> > >>> There are already some test which are written with Sunit from v2 challenges. > >>> and for the new one I could write the tests. > >>> > >>> But what I mean is that exercismv 3 wants that the code written by a student is submitted and that then the tests are run and a json file with if a test is successfull or with the tests errors is made. > >> > >> We do that for our server (not Json). > >> Do you have a spec of what should be the output? > >> It could be occasion for us to extract a runner and strengthen the logic of the test execution. > >> S > >> > >>> > >>> On v2 the tests were on the same image as the code written by a student. > >>> > >>> Roelof > >>> > >>> > >>> > >>> Op 13-8-2021 om 22:14 schreef stephane.ducasse(a)free.fr <mailto:stephane.ducasse@free.fr>: > >>>> Hi > >>>> > >>>>> As far as I see it standalone means work without a image. > >>>>> all the other test-runners run in a vm as far as I know how exercism works. > >>>> > >>>> Nope. :) > >>>> You see in ruby or python or Javascript, you cannot run a software without a kernel (and a kernek is an image that cannot be saved and it often created > >>>> using some hardcoded C code - but this is the same). They just cannot save the kernel once loaded with libraries but this is the same. > >>>> > >>>> So if we can load tests and execute tests without clicking on a button interactively. > >>>> Yes we can. > >>>> > >>>> This is what we are doing since we have the jenkins test runner (since 2009 or before) and this is what you have when you > >>>> run tests on travis or github actions. > >>>> > >>>> So now the point is to know if their infrastructure needs a script to run the tests > >>>> - how to identify them > >>>> - how to execute them > >>>> > >>>> Because in Pharo we can write tests, identify them and execute them > >>>> Interactively but also from the command-line. > >>>> > >>>> Did you already write a test? > >>>> Because if not, it super super important and I will release some a booklet on Testing in Pharo. > >>>> and also a new chapter ofr Pharo by example 9 > >>>> > >>>> https://pharoweekly.wordpress.com/2021/08/04/ann-chapter-sunit-of-pharo-9-b… <https://pharoweekly.wordpress.com/2021/08/04/ann-chapter-sunit-of-pharo-9-b…> > >>>> > >>>> S > >>>> > >>>>> > >>>>> Roelof > >>>>> > >>>>> > >>>>> > >>>>> Op 13-8-2021 om 21:50 schreef stephane.ducasse(a)free.fr <mailto:stephane.ducasse@free.fr>: > >>>>>> Hello > >>>>>> > >>>>>> Can you be more specific because Pharo got since day 0 (and I would say even before) a test runner? > >>>>>> The SUnit framework is there already. > >>>>>> We were thinking to extract a runner object to make it first class from the core framework. > >>>>>> But beside that it is working, maintained, extended (now we have parametrised tests) and we have (I should publish it) supports for example (tests without setUp) > >>>>>> > >>>>>> Then what is standalone? > >>>>>> > >>>>>> S. > >>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> > >>>>>>> For the new version of exercism which is due in a few weeks, the pharo track needs a test-runner, > >>>>>>> > >>>>>>> a example of that can be found here : https://github.com/exercism/ruby-test-runner/tree/main/lib <https://github.com/exercism/ruby-test-runner/tree/main/lib> <https://github.com/exercism/ruby-test-runner/tree/main/lib <https://github.com/exercism/ruby-test-runner/tree/main/lib>> > >>>>>>> > >>>>>>> > >>>>>>> first question : Can this be easily be done in pharo? > >>>>>>> > >>>>>>> second question : can it also be standalone? > >>>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> > >>>>>>> Roelof > >>>> > >>> > >> > >> > > >

Aug. 16, 2021

File-in Issue - Pharo 9

by Craig Johnson

Hi All, I just filed-out a small project that I playing with, and refreshed the image.Â The new image cannot file-in the package from the File Browser. "Instance of RubSmalltalkEditor did not understand #fileItIn". Is there another way to file-in the package? Thanks Craig

Aug. 15, 2021

Re: Exercism v3 problems

by Roelof Wobben

Aug. 15, 2021

Re: ABBench: Lightweight Microbenchmarking Library

by emdonahu＠gmail.com

Thanks. Yeah, that is to determine a stopping criterion: if one path is clearly faster it needs fewer samples to determine that with confidence. Evan

Aug. 15, 2021

Re: ABBench: Lightweight Microbenchmarking Library

by Kasper Osterbye

Cheers That looks really interesting - I saw that you use an underlying statistical test for the nul hypothesis. That is a cool way to approach it. Best, Kasper > On 12 Aug 2021, at 19.44, Evan Donahue <emdonahu(a)gmail.com> wrote: > > Hello, > > I've just released a utility I've been using for the past few years to help optimize Pharo code. It's a library that makes it easy to check whether an optimization has improved performance by wrapping the optimization and the old code in an if block and executing the optimized and unoptimized paths repeatedly under the same runtime conditions to determine which is faster. > > Basic usage is to wrap changes to the code in if blocks like so: > > ABBench a: [ ...existing code...] b: [...optimized code...] > > And then run the A/B test by printing: > > ABBench bench: [...some main method...] > > I have found it to make performance testing simple and quick enough that I actually do it. Perhaps someone else will find it useful. > > Install with: > > Metacello new > githubUser: 'emdonahue' project: 'ABBench' commitish: 'master' path: ''; > baseline: 'ABBench'; > load. > > More details can be found here: > > https://github.com/emdonahue/ABBench <https://github.com/emdonahue/ABBench> > > Cheers, > Evan

Aug. 14, 2021

Re: Pharo-SQLite3: closing connections immediately and deleting the database file

by vinref＠gmail.com

Hi I double-check changes to the db by running the SQLite3 client in a terminal. The memory db is only accessible by the same client/session so it wonât work. I also run multiple processes doing different things in the same image so each process needs its own connection/handle to SQLite3 so that wont work either. I am using DROP TABLE IF NOT EXISTS to drop all tables before the main schema and it works perfectly. But I did think of using a SQLite3 memory db to hold session info - i.e, cookies. Or I could just use a Dictionary. I havenât implemented this yet but does anyone have any thoughts? Vince

Aug. 13, 2021

Re: Pharo-SQLite3: closing connections immediately and deleting the database file

by JuliÃ¡n Maestri

As far as I know you need to tell it to open a file called :memory: and in Pharo-SQLite3 you should be able to use: SQLite3Connection memory I've never done this before in Pharo, but it's worth trying, it should be faster and easier to set up. https://www.sqlite.org/inmemorydb.html https://github.com/pharo-rdbms/Pharo-SQLite3/blob/7614fe8d0ac03fc94ed6be7e6… On Fri, 13 Aug 2021 at 00:26, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > After I set up the tests I knew that was possible, but never knew how > to actually do it. > > Regards! > > Esteban A. Maringolo > > On Thu, Aug 12, 2021 at 8:55 PM JuliÃ¡n Maestri <serpi90(a)gmail.com> wrote: > > > > Not exactly what you are asking for, but did you consider using sqlite > in memory? > > > > On Sat, 7 Aug 2021 at 23:23, Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > >> > >> I've been doing exactly that. It is, creating a new DB file for each > >> test, and I was having the same problem as you. > >> > >> I suggested a change to the driver to cover that situation: > >> https://github.com/pharo-rdbms/Pharo-SQLite3/pull/22/files > >> > >> Try applying that change and see if that works. > >> > >> I still prefer to recreate the database, it will give you a full fresh > >> start, and if you want you can halt before the deletion of the db, to > >> analyze its internal state. > >> > >> Best regards! > >> > >> > >> Esteban A. Maringolo > >> > >> On Sat, Aug 7, 2021 at 11:13 PM <vinref(a)gmail.com> wrote: > >> > > >> > Hi > >> > > >> > Actually I will just do a bunch of > >> > > >> > DROP TABLE IF EXISTS > >> > > >> > instead of dropping the db altogether. > >> > > >> > Thanks, Vince >

Aug. 13, 2021

Re: Pharo-SQLite3: closing connections immediately and deleting the database file

by Esteban Maringolo

After I set up the tests I knew that was possible, but never knew how to actually do it. Regards! Esteban A. Maringolo On Thu, Aug 12, 2021 at 8:55 PM JuliÃ¡n Maestri <serpi90(a)gmail.com> wrote: > > Not exactly what you are asking for, but did you consider using sqlite in memory? > > On Sat, 7 Aug 2021 at 23:23, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> I've been doing exactly that. It is, creating a new DB file for each >> test, and I was having the same problem as you. >> >> I suggested a change to the driver to cover that situation: >> https://github.com/pharo-rdbms/Pharo-SQLite3/pull/22/files >> >> Try applying that change and see if that works. >> >> I still prefer to recreate the database, it will give you a full fresh >> start, and if you want you can halt before the deletion of the db, to >> analyze its internal state. >> >> Best regards! >> >> >> Esteban A. Maringolo >> >> On Sat, Aug 7, 2021 at 11:13 PM <vinref(a)gmail.com> wrote: >> > >> > Hi >> > >> > Actually I will just do a bunch of >> > >> > DROP TABLE IF EXISTS >> > >> > instead of dropping the db altogether. >> > >> > Thanks, Vince

Aug. 13, 2021

Re: Pharo-SQLite3: closing connections immediately and deleting the database file

by JuliÃ¡n Maestri

Not exactly what you are asking for, but did you consider using sqlite in memory? On Sat, 7 Aug 2021 at 23:23, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > I've been doing exactly that. It is, creating a new DB file for each > test, and I was having the same problem as you. > > I suggested a change to the driver to cover that situation: > https://github.com/pharo-rdbms/Pharo-SQLite3/pull/22/files > > Try applying that change and see if that works. > > I still prefer to recreate the database, it will give you a full fresh > start, and if you want you can halt before the deletion of the db, to > analyze its internal state. > > Best regards! > > > Esteban A. Maringolo > > On Sat, Aug 7, 2021 at 11:13 PM <vinref(a)gmail.com> wrote: > > > > Hi > > > > Actually I will just do a bunch of > > > > DROP TABLE IF EXISTS > > > > instead of dropping the db altogether. > > > > Thanks, Vince >

Aug. 12, 2021

ABBench: Lightweight Microbenchmarking Library

by Evan Donahue

Hello, I've just released a utility I've been using for the past few years to help optimize Pharo code. It's a library that makes it easy to check whether an optimization has improved performance by wrapping the optimization and the old code in an if block and executing the optimized and unoptimized paths repeatedly under the same runtime conditions to determine which is faster. Basic usage is to wrap changes to the code in if blocks like so: ABBench a: [ ...existing code...] b: [...optimized code...] And then run the A/B test by printing: ABBench bench: [...some main method...] I have found it to make performance testing simple and quick enough that I actually do it. Perhaps someone else will find it useful. Install with: Metacello new githubUser: 'emdonahue' project: 'ABBench' commitish: 'master' path: ''; baseline: 'ABBench'; load. More details can be found here: https://github.com/emdonahue/ABBench Cheers, Evan

Aug. 12, 2021

Exercism v3 problems

by r.wobben＠home.nl

Hello, For the new version of exercism which is due in a few weeks, the pharo track needs a test-runner, a example of that can be found here : https://github.com/exercism/ruby-test-runner/tree/main/lib first question : Can this be easily be done in pharo? second question : can it also be standalone? Regards, Roelof

Aug. 10, 2021

Re: Logging Frameworks

by Esteban Maringolo

Hi Gabriel, I found this Beacon-Server [1] that could work, it would be a good use case in a docker environment where you have several worker images talking to a single beacon-server-container. Regards! [1] https://github.com/grype/Beacon-Server Esteban A. Maringolo On Mon, Aug 9, 2021 at 9:10 AM Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > Beacon is integrated as part of Pharo now, but the repository includes more logger options. Maybe some option there allows forwarding the logs to a centralized place. I'm also interested in other's experiences regarding logging options because we want to settle on some option as the default for our Pharo components. > > On Sun, Aug 8, 2021 at 11:29 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> What are the current options for logging? >> >> Beacon seems to be the most modern one, but the Github repository >> doesn't seem very active (maybe it forked somewhere else). >> >> Given that the logs might come from different worker images, is there >> something that can work via HTTP or similar? (it is, forwarding the >> logged events to a server). >> >> Regards! >> >> ps: I think I've asked this before, but couldn't find my previous >> question about it. >> >> >> Esteban A. Maringolo

Aug. 9, 2021

Re: Logging Frameworks

by Esteban Maringolo

That is my impression with Beacon, there was a lot of discussion about it and then never heard of it again. Is your code available somewhere? Regards! ps: There is also TinyLogger that works by means of a DynamicVariable, but I liked the idea of using objects instead of just strings for logging (which I'm manually doing now). Esteban A. Maringolo On Mon, Aug 9, 2021 at 9:16 AM Norbert Hartl <norbert(a)hartl.name> wrote: > > Beacon is a sad story. There was a lot of initiative and motivation for loggers which was killed. But it is still a good foundation to build something useful on top of it. I integrated a syslog option when I was working on beacon. In my projects Iâve done a sender to elasticsearch for logging. Beaconâs design allows all of that. After motivation died nobody put some love into it again. Thatâs all! > > Maybe time to pick it up again. But I personally have too much on my plate right now to take another attempt. > > Norbert > > > Am 09.08.2021 um 14:08 schrieb Gabriel Cotelli <g.cotelli(a)gmail.com>: > > Beacon is integrated as part of Pharo now, but the repository includes more logger options. Maybe some option there allows forwarding the logs to a centralized place. I'm also interested in other's experiences regarding logging options because we want to settle on some option as the default for our Pharo components. > > On Sun, Aug 8, 2021 at 11:29 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> What are the current options for logging? >> >> Beacon seems to be the most modern one, but the Github repository >> doesn't seem very active (maybe it forked somewhere else). >> >> Given that the logs might come from different worker images, is there >> something that can work via HTTP or similar? (it is, forwarding the >> logged events to a server). >> >> Regards! >> >> ps: I think I've asked this before, but couldn't find my previous >> question about it. >> >> >> Esteban A. Maringolo > >

Aug. 9, 2021

Re: Logging Frameworks

by Norbert Hartl

Beacon is a sad story. There was a lot of initiative and motivation for loggers which was killed. But it is still a good foundation to build something useful on top of it. I integrated a syslog option when I was working on beacon. In my projects Iâve done a sender to elasticsearch for logging. Beaconâs design allows all of that. After motivation died nobody put some love into it again. Thatâs all! Maybe time to pick it up again. But I personally have too much on my plate right now to take another attempt. Norbert > Am 09.08.2021 um 14:08 schrieb Gabriel Cotelli <g.cotelli(a)gmail.com>: > > Beacon is integrated as part of Pharo now, but the repository includes more logger options. Maybe some option there allows forwarding the logs to a centralized place. I'm also interested in other's experiences regarding logging options because we want to settle on some option as the default for our Pharo components. > > On Sun, Aug 8, 2021 at 11:29 AM Esteban Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > What are the current options for logging? > > Beacon seems to be the most modern one, but the Github repository > doesn't seem very active (maybe it forked somewhere else). > > Given that the logs might come from different worker images, is there > something that can work via HTTP or similar? (it is, forwarding the > logged events to a server). > > Regards! > > ps: I think I've asked this before, but couldn't find my previous > question about it. > > > Esteban A. Maringolo

Aug. 9, 2021

Re: Logging Frameworks

by Gabriel Cotelli

Beacon is integrated as part of Pharo now, but the repository includes more logger options. Maybe some option there allows forwarding the logs to a centralized place. I'm also interested in other's experiences regarding logging options because we want to settle on some option as the default for our Pharo components. On Sun, Aug 8, 2021 at 11:29 AM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > What are the current options for logging? > > Beacon seems to be the most modern one, but the Github repository > doesn't seem very active (maybe it forked somewhere else). > > Given that the logs might come from different worker images, is there > something that can work via HTTP or similar? (it is, forwarding the > logged events to a server). > > Regards! > > ps: I think I've asked this before, but couldn't find my previous > question about it. > > > Esteban A. Maringolo >

Aug. 9, 2021