- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Denis Kudriashov

Hi 2016-08-29 8:25 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Glenn, > > Thanks a lot for this experiment. Could you send us the code snippet so > people can play with it? > Or some links where to download image with Bloc-Tests

Aug. 29, 2016

Re: [Pharo-dev] Binary selector and special characters

by stepharo

Thierry If you have a better editor control even better :) > > Syntax wise, one could consider "" to be inside a comment (i.e. do not > split into two comments if encountered inside a comment, as it is done > now). This one could be nice too :)

Aug. 29, 2016

Re: [Pharo-dev] Binary selector and special characters

by Thierry Goubier

2016-08-29 10:58 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Stef, > > 2016-08-29 8:35 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> This is a really nice and important question. >> I would really have a clear answer because it will make the system more >> stable. >> >> If you can build an analysis and let us know it would be really great. >> >> >> Something related but not on the same topic is that I would love to have >> a syntax for nested comments. >> >> This is really annoying to have to uncomment parts when we have to >> comment a large part. We discussed this back in 2007-2009 but we never did >> it. >> > > If your need is that (uncomment while commenting and the reverse), then > the answer is not a syntax change, but a better comment/uncomment command > in the editor. > > Now that you say that, I also have the issue. I'll have a try in > AltBrowser if I can get the behavior you'd like. > That works, but: - Single click select doesn't work very well (stops at the next double quotes instead of the end double quote) - The formatter likes to split double quotes (adding returns) - Backporting that to a standard editor is a mess, because there is a need to change the #enclose: method. Syntax wise, one could consider "" to be inside a comment (i.e. do not split into two comments if encountered inside a comment, as it is done now). Thierry > > Thierry > > >> >> >> Stef >> >> >> Le 28/8/16 Ã 12:17, Nicolai Hess a Ã©crit : >> >> Hi, >>> >>> where can I find a good reference about what characters are allowed as >>> binary selectors (from old syntax definition) and what is nowadays >>> allowed >>> by the implementations. >>> >>> And whether the current set of allowed binaries selector includes some >>> additions on >>> purpose or if this is just a bug of the parser. >>> >>> From what I found out, (Blue book and some other smalltalk syntax >>> definitions) >>> the current set of allowed characters includes the "special characters": >>> $! $% $& $* $+ $, $- $/ $< $= $> $? $@ $\ $| $~ >>> (some implementation do not allow $@ and some calls $- not a special >>> character >>> but allowed as binary selector character) >>> >>> And this is what String>>#numArgs uses. Therefore >>> >>> '-' numArgs "->1". >>> '!' numArgs "->1". >>> And for example: >>> 'Â§' numArgs "-> -1 (the -1 is indicating "not even a valid selector")" >>> >>> But I am interested in the characters not called "special characters and >>> not even in the range 0-126. >>> >>> The scanner allowes much more characters to be used as a selector name >>> (From the scanners typeTable) : >>> >>> {Character value: 1 . Character value: 2 . Character value: 3 . >>> Character value: 4 . Character value: 5 . Character value: 6 . Character >>> value: 7 . Character backspace . Character value: 11 . Character value: 14 >>> . Character value: 15 . Character value: 16 . Character value: 17 . >>> Character value: 18 . Character value: 19 . Character value: 20 . Character >>> value: 21 . Character value: 22 . Character value: 23 . Character value: 24 >>> . Character value: 25 . Character value: 26 . Character escape . Character >>> value: 28 . Character value: 29 . Character value: 30 . Character value: 31 >>> . $! . $% . $& . $* . $+ . $, . $- . $/ . $< . $= . $> . $? . $@ . $\ . $` >>> . $~ . Character delete . $â¬ . $ . $â . $Æ . $â . $â¦ . $â . $â¡ . $Ë . $â° . >>> $Å . $â¹ . $Å . $ . $Å½ . $ . $ . $â . $â . $â . $â . $â¢ . $â . $â . $Ë . $â¢ >>> . $Å¡ . $âº . $Å . $ . $Å¾ . $Å¸ . $ . $Â¡ . $Â¢ . $Â£ . $Â¤ . $Â¥ . $Â¦ . $Â§ . $Â¨ . >>> $Â© . $Â« . $Â¬ . $Â . $Â® . $Â¯ . $Â° . $Â± . $Â² . $Â³ . $Â´ . $Â¶ . $Â· . $Â¸ . $Â¹ . >>> $Â» . $Â¼ . $Â½ . $Â¾ . $Â¿ . $Ã . $Ã·} >>> >>> This means you can define a method with for example the name "Ã·". >>> >>> So , the question I want to ask. What do we want to allow as a binary >>> selector (character). >>> All that is nowadays "parseable" as binary selector, or only the set of >>> "special characters" >>> or something between both, and where to put this information, the "this >>> is an allowed binary >>> selector character" information? >>> >>> Thanks >>> Nicolai >>> >>> >> >> >

Aug. 29, 2016

Re: [Pharo-dev] Binary selector and special characters

by Nicolai Hess

2016-08-28 13:41 GMT+02:00 monty <monty2(a)programmer.net>: > See RBParserTest>>#testBinarySelectors > > It's based on the draft ANSI Smalltalk-80 standard. You integrated it. It > tests the RBParser's parsing of binary method definitions and message sends > of all binary selectors from 1 char upto 3 chars. (The Blue Book is more > restrictive than ANSI, limiting them to 2 chars max IIRC.) > > I wrote the test because of issues I had with the OldCompiler's handling > of selectors containing "|" and issues on other platforms like GemStone, so > the behavior I need and think is correct won't get broken without warning. > > Hi Monty, yes, but I am just wondering why the scanner interprets some characters as binary selector token, whereas they are not allowed as binary selectors. In the old scanner, the initialization of the type table just sets " binary token" as the default for all characters and changes some of them explicit to for example ($0 asciiValue to: $9 asciiValue) -> digit tokens #(9 10 12 13 32 ) -> delimiter token ... But RBScanner on the other hand explicitly sets some non-ascii characters to be used as "binary tokens" classificationTable at: 177 put: #binary. "plus-or-minus" classificationTable at: 183 put: #binary. "centered dot" classificationTable at: 215 put: #binary. "times" classificationTable at: 247 put: #binary. "divide" It looks like someone ( or somewhere ) it should be allowed to use these characters as a binary selector "#($Â± $Â· $Ã $Ã·)" Although later at the parsing step, using this tokens for binary message selectors isn't allowed. I think I will exclude these characters as binary selector tokens.

Aug. 29, 2016

Re: [Pharo-dev] Binary selector and special characters

by Thierry Goubier

Hi Stef, 2016-08-29 8:35 GMT+02:00 stepharo <stepharo(a)free.fr>: > This is a really nice and important question. > I would really have a clear answer because it will make the system more > stable. > > If you can build an analysis and let us know it would be really great. > > > Something related but not on the same topic is that I would love to have a > syntax for nested comments. > > This is really annoying to have to uncomment parts when we have to comment > a large part. We discussed this back in 2007-2009 but we never did it. > If your need is that (uncomment while commenting and the reverse), then the answer is not a syntax change, but a better comment/uncomment command in the editor. Now that you say that, I also have the issue. I'll have a try in AltBrowser if I can get the behavior you'd like. Thierry > > > Stef > > > Le 28/8/16 Ã 12:17, Nicolai Hess a Ã©crit : > > Hi, >> >> where can I find a good reference about what characters are allowed as >> binary selectors (from old syntax definition) and what is nowadays allowed >> by the implementations. >> >> And whether the current set of allowed binaries selector includes some >> additions on >> purpose or if this is just a bug of the parser. >> >> From what I found out, (Blue book and some other smalltalk syntax >> definitions) >> the current set of allowed characters includes the "special characters": >> $! $% $& $* $+ $, $- $/ $< $= $> $? $@ $\ $| $~ >> (some implementation do not allow $@ and some calls $- not a special >> character >> but allowed as binary selector character) >> >> And this is what String>>#numArgs uses. Therefore >> >> '-' numArgs "->1". >> '!' numArgs "->1". >> And for example: >> 'Â§' numArgs "-> -1 (the -1 is indicating "not even a valid selector")" >> >> But I am interested in the characters not called "special characters and >> not even in the range 0-126. >> >> The scanner allowes much more characters to be used as a selector name >> (From the scanners typeTable) : >> >> {Character value: 1 . Character value: 2 . Character value: 3 . Character >> value: 4 . Character value: 5 . Character value: 6 . Character value: 7 . >> Character backspace . Character value: 11 . Character value: 14 . Character >> value: 15 . Character value: 16 . Character value: 17 . Character value: 18 >> . Character value: 19 . Character value: 20 . Character value: 21 . >> Character value: 22 . Character value: 23 . Character value: 24 . Character >> value: 25 . Character value: 26 . Character escape . Character value: 28 . >> Character value: 29 . Character value: 30 . Character value: 31 . $! . $% . >> $& . $* . $+ . $, . $- . $/ . $< . $= . $> . $? . $@ . $\ . $` . $~ . >> Character delete . $â¬ . $ . $â . $Æ . $â . $â¦ . $â . $â¡ . $Ë . $â° . $Å . $â¹ >> . $Å . $ . $Å½ . $ . $ . $â . $â . $â . $â . $â¢ . $â . $â . $Ë . $â¢ . $Å¡ . >> $âº . $Å . $ . $Å¾ . $Å¸ . $ . $Â¡ . $Â¢ . $Â£ . $Â¤ . $Â¥ . $Â¦ . $Â§ . $Â¨ . $Â© . >> $Â« . $Â¬ . $Â . $Â® . $Â¯ . $Â° . $Â± . $Â² . $Â³ . $Â´ . $Â¶ . $Â· . $Â¸ . $Â¹ . $Â» . >> $Â¼ . $Â½ . $Â¾ . $Â¿ . $Ã . $Ã·} >> >> This means you can define a method with for example the name "Ã·". >> >> So , the question I want to ask. What do we want to allow as a binary >> selector (character). >> All that is nowadays "parseable" as binary selector, or only the set of >> "special characters" >> or something between both, and where to put this information, the "this >> is an allowed binary >> selector character" information? >> >> Thanks >> Nicolai >> >> > >

Aug. 29, 2016

Re: [Pharo-dev] IceBerg and push for projects vs packages

by Nicolas Passerini

Well, I am not sure if this has to do with Iceberg itself, because Iceberg does nothing with dependencies. But I am not sure that a ConfigurationOfXXX really has information of only one package. Normally you will have only one configuration for each project, am I wrong? Then the configuration specifies (among other stuff) dependencies between the parts (packages) of your project... I think this is right. If you depend in another project, then you should not depend in specific packages but in another configuration. The problem here is that we are (at least Iceberg is) assuming a correlation between project and repository, because in fact Iceberg handles repositories. If a project would be spawn in several repositories, at least now Iceberg can't do anything about it, it will treat them as independent "projects". I am not sure about changing this logic in the near future, and also we should think if that is not a Cargo/Metacello feature. On Sat, Aug 27, 2016 at 10:35 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > one thing that I wanted to ask about IceBerg --- during the IceBerg talk > Nico mentioned that we need to think in terms of projects. > > Now I understand that perspective, because that's how git behaves and > that's how _I_ think, > > however at the same time, there is a strong push for focusing on > packages... having each package describing it's dependencies, etc. > > So my question is, how do those two views interact with each other? > Because I feel like they are going against each other. > > Peter > >

Aug. 29, 2016

Re: [Pharo-dev] Binary selector and special characters

by stepharo

This is a really nice and important question. I would really have a clear answer because it will make the system more stable. If you can build an analysis and let us know it would be really great. Something related but not on the same topic is that I would love to have a syntax for nested comments. This is really annoying to have to uncomment parts when we have to comment a large part. We discussed this back in 2007-2009 but we never did it. Stef Le 28/8/16 Ã 12:17, Nicolai Hess a Ã©crit : > Hi, > > where can I find a good reference about what characters are allowed as > binary selectors (from old syntax definition) and what is nowadays allowed > by the implementations. > > And whether the current set of allowed binaries selector includes some > additions on > purpose or if this is just a bug of the parser. > > From what I found out, (Blue book and some other smalltalk syntax > definitions) > the current set of allowed characters includes the "special characters": > $! $% $& $* $+ $, $- $/ $< $= $> $? $@ $\ $| $~ > (some implementation do not allow $@ and some calls $- not a special > character > but allowed as binary selector character) > > And this is what String>>#numArgs uses. Therefore > > '-' numArgs "->1". > '!' numArgs "->1". > And for example: > 'Â§' numArgs "-> -1 (the -1 is indicating "not even a valid selector")" > > But I am interested in the characters not called "special characters and > not even in the range 0-126. > > The scanner allowes much more characters to be used as a selector name > (From the scanners typeTable) : > > {Character value: 1 . Character value: 2 . Character value: 3 . > Character value: 4 . Character value: 5 . Character value: 6 . > Character value: 7 . Character backspace . Character value: 11 . > Character value: 14 . Character value: 15 . Character value: 16 . > Character value: 17 . Character value: 18 . Character value: 19 . > Character value: 20 . Character value: 21 . Character value: 22 . > Character value: 23 . Character value: 24 . Character value: 25 . > Character value: 26 . Character escape . Character value: 28 . > Character value: 29 . Character value: 30 . Character value: 31 . $! . > $% . $& . $* . $+ . $, . $- . $/ . $< . $= . $> . $? . $@ . $\ . $` . > $~ . Character delete . $â¬ . $ . $â . $Æ . $â . $â¦ . $â . $â¡ . $Ë . $â° > . $Å . $â¹ . $Å . $ . $Å½ . $ . $ . $â . $â . $â . $â . $â¢ . $â . $â . > $Ë . $â¢ . $Å¡ . $âº . $Å . $ . $Å¾ . $Å¸ . $ . $Â¡ . $Â¢ . $Â£ . $Â¤ . $Â¥ . > $Â¦ . $Â§ . $Â¨ . $Â© . $Â« . $Â¬ . $Â . $Â® . $Â¯ . $Â° . $Â± . $Â² . $Â³ . $Â´ . > $Â¶ . $Â· . $Â¸ . $Â¹ . $Â» . $Â¼ . $Â½ . $Â¾ . $Â¿ . $Ã . $Ã·} > > This means you can define a method with for example the name "Ã·". > > So , the question I want to ask. What do we want to allow as a binary > selector (character). > All that is nowadays "parseable" as binary selector, or only the set > of "special characters" > or something between both, and where to put this information, the > "this is an allowed binary > selector character" information? > > Thanks > Nicolai >

Aug. 29, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Tudor Girba

Hi Glenn, Thanks a lot for this experiment. Could you send us the code snippet so people can play with it? The question is if perhaps we can identify a slimmer announcement support so that people can choose depending on requirements (e.g. parallelism or not). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow" > On 28 Aug 2016, at 21:11, Glenn CavarlÃ© <glenn.cavarle(a)gmail.com> wrote: > > Hi all, > Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of > Announcer in Bloc. > I made some test cases in Bloc-Tests to compare performances between > Announcer and BlEventRegistry. > The result is that Announcer is at least 5x slower in all tested cases. > Bloc has only specific needs about event dispatching, the first one is the > efficiency during event propagation. > It may be interesting to investigate why Announcer is slower and also what > are the uncovered cases in BlEventRegistry. > So, i'm interested in continuing our discussion about that. > > Regards, > Glenn. > > > > ----- > Glenn CavarlÃ© > -- > View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 29, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Henrik Nergaard

Probably from the use of critical (mutex), the way #subscriptionsHandling: is done, and that Announcer is built for X number of announcers and Y number of subscribers, which means that each announcement the announcer has to filter and find the correct subscribers. ---- | ann a | ann := Announcer new. ann when: Announcement do: [ :e ]. a := Announcement new. [[ ann announce: a ] bench ] timeProfile ----- Other drawbacks to consider when using announcements: Memory overhead from the Announcer object and each subscription. Memory ownership, the announcement subscriptions will strongly reference the announcement target unless the announcement is weakly, which can lead to memory leakage especially if strong and weak subscriptions are mixed in certain situations (see the mailing list from around the release of Pharo 6). This also leads to code where the announcer is the one who owns the target (multiple times if there are different announcements), which makes understanding who references what etc.. much harder to understand. In many places the control/message flow, and the relationship between the different parts of a bigger object tends to become much more difficult to understand (For example Rubric). Announcer usage shines when there is a need for a common place that X objects can communicate Y messages to Z recipients without needing to know who sends what, or who wants to receive what (For example System Announcements). Communication when only one Object "A" announces to another Object(s) "B", is better implemented as A referencing B, then B implements the necessary methods needed for this communication. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Glenn CavarlÃ© Sent: Sunday, August 28, 2016 9:11 PM To: pharo-dev(a)lists.pharo.org Subject: [Pharo-dev] About the non-use of Announcer in Bloc Hi all, Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. I made some test cases in Bloc-Tests to compare performances between Announcer and BlEventRegistry. The result is that Announcer is at least 5x slower in all tested cases. Bloc has only specific needs about event dispatching, the first one is the efficiency during event propagation. It may be interesting to investigate why Announcer is slower and also what are the uncovered cases in BlEventRegistry. So, i'm interested in continuing our discussion about that. Regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2016

About the non-use of Announcer in Bloc

by Glenn CavarlÃ©

Hi all, Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. I made some test cases in Bloc-Tests to compare performances between Announcer and BlEventRegistry. The result is that Announcer is at least 5x slower in all tested cases. Bloc has only specific needs about event dispatching, the first one is the efficiency during event propagation. It may be interesting to investigate why Announcer is slower and also what are the uncovered cases in BlEventRegistry. So, i'm interested in continuing our discussion about that. Regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2016