February 2017 - Pharo-users

About asSymbol message , some questions in my mind

by lb

Hi, Dnenis Thank you. Your sample gives me some tips on AI , NLP. Cheers Bing å¨ 2017-02-11 22:18:14ï¼"Denis Kudriashov" <dionisiydk(a)gmail.com> åéï¼ 2017-02-11 8:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: The concept of 'meaning' is defined by the user, the usage, not by the Symbol itself. A Symbol with a space cannot be a selector (message/method) name But it could be: Point methodDict at: #'name with space' put: Point>>#x. 2@3 perform: #'name with space' "==> 2" Only problem that we could not use them with normal syntax

Feb. 12, 2017

Re: [Pharo-users] About asSymbol message , some questions in my mind

by lb

Hi Benï¼ Thank you very much, your answer make me clear like water. My question aimed on where, which type errors occur when perform a message. My usecase. when perform: aMessage(with a space), get DNU error , cannot find out by eyes directly. asMessage is better than asSymbol. Cheers Bing At 2017-02-12 00:39:55, "Ben Coman" <btc(a)openinworld.com> wrote: >Hi Bing Liang, > >Thanks for your comments. Fresh eyes provide interesting perspectives >on things we take for granted. > >On Sat, Feb 11, 2017 at 4:41 PM, lb <liangbing64(a)126.com> wrote: >> Thank you, Sven >> gradually clear. >> 1. Symbol as String subclass, only guarantees a symbol object only one in >> system, use ==; >> 2. keywords (selector name method name) are spectial symbols, without space >> or forbided characters; >> 3. perform: aSymbol, means perform: aKeyword, > >Not exactly. It means perform a "message" where there are three types >of messages... >* unary, like #printString >* binary, like #+ >* keyword, like #perform: or >#subclass:instanceVariableNames:classVariableNames:package: >having a colon appended to each keyword > >> Should we add asKeyword to String, >> let >> perform: aString asKeyword > >or alternatively per above... perform: aString asMessage > >> not >> perform: aString asSymbol ? > >In the case that aString contained a space, >presumably #asMessage would produce a runtime error in asMessage >whereas #asSymbol would produce a runtime error in #perform: >I guess there is a minor benefit of failing early but will that make >much difference in practice. >Do you have a use case where it makes a major difference? > > >> At 2017-02-11 15:51:49, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: >>>Hi Bing, >>> >>>Yes, any character is allowed in a Symbol. There is even special syntax >>> that allows such Symbols to be represented literally. >>> >>>'a b' asSymbol. >>> >>> => #'a b' >>> >>>Although it might be confusing, I don't see any problem. >>> >>>The concept of 'meaning' is defined by the user, the usage, not by the >>> Symbol itself. A Symbol with a space cannot be a selector (message/method) >>> name, but that does not mean a Symbol with a space could not be useful in >>> some other context. >>> >>>> On 11 Feb 2017, at 05:56, lb <liangbing64(a)126.com> wrote: >>>> >>>> Hi, >>>> I know Symbol is subclass of String. >>>> Any string object can become symbol object by sending 'asSymbol' >>>> message.. >>>> I think symbol must has its meaning in common use, so the symbol should >>>> be composed of alphabet or number âwithout spaceâ. > >Different domains have different common usage. >IIUC, Smalltalk's definition of symbol is from the 1970s. >Pharo is not overly constrained by Smalltalk traditions, but there >must be sufficient gain to balance deviations from consistency with >other Smalltalks. > >>>> >>>> BUT There are not compliant below >>>> 1. ' ' asSymbol >>>> no meaning >>>> 2. '$%%&' asSymbol >>>> no meaning >>>> 3. 'sign' asSymbol = 'sign ' asSymbol >>> false because of space. >>>> 3. ' one two three ' asSymbol >>> I think It should >>>> become three symbols = #one, #two, #three >>>> >>>> >>>> Maybe my understanding is wrong. > >no problem. Being wrong is a great way to learn ;) > >cheers -ben >

Feb. 12, 2017

Re: [Pharo-users] Citezen bug MessageNotUnderstood: Metaclass>>allMethodsInCategory:

by Offray Vladimir Luna CÃ¡rdenas

Thanks to Cyril I have fixed the bug. Now is called #allSelectorsInProtocol. How can I propose a bug fix for the citezen package? Is good to have a chat channel for this knowledge... it's a shame that all this will be lost, like "tears in the rain" because we're relying on privative infrastructure for community memory... :-/. I have started to test rocket.chat/deploy and seems pretty good. I have deployed https://pharochat.rocket.chat/ in seconds. Now I'm asking about data migration from slack and costs for open source communities. Cheers, Offray On 11/02/17 17:30, Offray Vladimir Luna CÃ¡rdenas wrote: > Hi, > > I'm adding some Zotero[1] integration for my Grafoscopio project, now > that I'm preparing a couple of papers for my PhD. For that, I'm using > Citezen, but when I try to run the renderers to create bibTeX outputs > I got the error "MessageNotUnderstood: > Metaclass>>allMethodsInCategory:". How can I solve this? > > [1] http://zotero.org/ > > Thanks, > > Offray > > >

Feb. 11, 2017

Citezen bug MessageNotUnderstood: Metaclass>>allMethodsInCategory:

by Offray Vladimir Luna CÃ¡rdenas

Hi, I'm adding some Zotero[1] integration for my Grafoscopio project, now that I'm preparing a couple of papers for my PhD. For that, I'm using Citezen, but when I try to run the renderers to create bibTeX outputs I got the error "MessageNotUnderstood: Metaclass>>allMethodsInCategory:". How can I solve this? [1] http://zotero.org/ Thanks, Offray

Feb. 11, 2017

Re: [Pharo-users] About asSymbol message , some questions in my mind

by Ben Coman

On Sun, Feb 12, 2017 at 12:39 AM, Ben Coman <btc(a)openinworld.com> wrote: > Hi Bing Liang, > > Thanks for your comments. Fresh eyes provide interesting perspectives > on things we take for granted. > > On Sat, Feb 11, 2017 at 4:41 PM, lb <liangbing64(a)126.com> wrote: >> Thank you, Sven >> gradually clear. >> 1. Symbol as String subclass, only guarantees a symbol object only one in >> system, use ==; >> 2. keywords (selector name method name) are spectial symbols, without space >> or forbided characters; >> 3. perform: aSymbol, means perform: aKeyword, > > Not exactly. It means perform a "message" where there are three types > of messages... > * unary, like #printString > * binary, like #+ > * keyword, like #perform: or > #subclass:instanceVariableNames:classVariableNames:package: > having a colon appended to each keyword > >> Should we add asKeyword to String, >> let >> perform: aString asKeyword > > or alternatively per above... perform: aString asMessage > >> not >> perform: aString asSymbol ? > > In the case that aString contained a space, > presumably #asMessage would produce a runtime error in asMessage > whereas #asSymbol would produce a runtime error in #perform: > I guess there is a minor benefit of failing early but will that make > much difference in practice. > Do you have a use case where it makes a major difference? > > >> At 2017-02-11 15:51:49, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: >>>Hi Bing, >>> >>>Yes, any character is allowed in a Symbol. There is even special syntax >>> that allows such Symbols to be represented literally. >>> >>>'a b' asSymbol. >>> >>> => #'a b' >>> >>>Although it might be confusing, I don't see any problem. >>> >>>The concept of 'meaning' is defined by the user, the usage, not by the >>> Symbol itself. A Symbol with a space cannot be a selector (message/method) >>> name, but that does not mean a Symbol with a space could not be useful in >>> some other context. >>> >>>> On 11 Feb 2017, at 05:56, lb <liangbing64(a)126.com> wrote: >>>> >>>> Hi, >>>> I know Symbol is subclass of String. >>>> Any string object can become symbol object by sending 'asSymbol' >>>> message.. >>>> I think symbol must has its meaning in common use, so the symbol should >>>> be composed of alphabet or number âwithout spaceâ. > > Different domains have different common usage. > IIUC, Smalltalk's definition of symbol is from the 1970s. > Pharo is not overly constrained by Smalltalk traditions, but there > must be sufficient gain to balance deviations from consistency with > other Smalltalks. > >>>> >>>> BUT There are not compliant below >>>> 1. ' ' asSymbol >>>> no meaning >>>> 2. '$%%&' asSymbol >>>> no meaning >>>> 3. 'sign' asSymbol = 'sign ' asSymbol >>> false because of space. >>>> 3. ' one two three ' asSymbol >>> I think It should >>>> become three symbols = #one, #two, #three >>>> >>>> >>>> Maybe my understanding is wrong. > > no problem. Being wrong is a great way to learn ;) > > cheers -ben P.S. Even wikipedia says "Symbols can contain whitespace (and all other characters)" https://en.wikipedia.org/wiki/Symbol_(programming) so it must be okay ;) cheers -ben

Feb. 11, 2017

Re: [Pharo-users] About asSymbol message , some questions in my mind

by Ben Coman

Hi Bing Liang, Thanks for your comments. Fresh eyes provide interesting perspectives on things we take for granted. On Sat, Feb 11, 2017 at 4:41 PM, lb <liangbing64(a)126.com> wrote: > Thank you, Sven > gradually clear. > 1. Symbol as String subclass, only guarantees a symbol object only one in > system, use ==; > 2. keywords (selector name method name) are spectial symbols, without space > or forbided characters; > 3. perform: aSymbol, means perform: aKeyword, Not exactly. It means perform a "message" where there are three types of messages... * unary, like #printString * binary, like #+ * keyword, like #perform: or #subclass:instanceVariableNames:classVariableNames:package: having a colon appended to each keyword > Should we add asKeyword to String, > let > perform: aString asKeyword or alternatively per above... perform: aString asMessage > not > perform: aString asSymbol ? In the case that aString contained a space, presumably #asMessage would produce a runtime error in asMessage whereas #asSymbol would produce a runtime error in #perform: I guess there is a minor benefit of failing early but will that make much difference in practice. Do you have a use case where it makes a major difference? > At 2017-02-11 15:51:49, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: >>Hi Bing, >> >>Yes, any character is allowed in a Symbol. There is even special syntax >> that allows such Symbols to be represented literally. >> >>'a b' asSymbol. >> >> => #'a b' >> >>Although it might be confusing, I don't see any problem. >> >>The concept of 'meaning' is defined by the user, the usage, not by the >> Symbol itself. A Symbol with a space cannot be a selector (message/method) >> name, but that does not mean a Symbol with a space could not be useful in >> some other context. >> >>> On 11 Feb 2017, at 05:56, lb <liangbing64(a)126.com> wrote: >>> >>> Hi, >>> I know Symbol is subclass of String. >>> Any string object can become symbol object by sending 'asSymbol' >>> message.. >>> I think symbol must has its meaning in common use, so the symbol should >>> be composed of alphabet or number âwithout spaceâ. Different domains have different common usage. IIUC, Smalltalk's definition of symbol is from the 1970s. Pharo is not overly constrained by Smalltalk traditions, but there must be sufficient gain to balance deviations from consistency with other Smalltalks. >>> >>> BUT There are not compliant below >>> 1. ' ' asSymbol >>>> no meaning >>> 2. '$%%&' asSymbol >>>> no meaning >>> 3. 'sign' asSymbol = 'sign ' asSymbol >>> false because of space. >>> 3. ' one two three ' asSymbol >>> I think It should >>> become three symbols = #one, #two, #three >>> >>> >>> Maybe my understanding is wrong. no problem. Being wrong is a great way to learn ;) cheers -ben

Feb. 11, 2017

Re: [Pharo-users] About asSymbol message , some questions in my mind

by Sven Van Caekenberghe

> On 11 Feb 2017, at 15:18, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-02-11 8:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > The concept of 'meaning' is defined by the user, the usage, not by the Symbol itself. A Symbol with a space cannot be a selector (message/method) name > > But it could be: > > Point methodDict at: #'name with space' put: Point>>#x. > > 2@3 perform: #'name with space' "==> 2" > > Only problem that we could not use them with normal syntax Cool. Or we could use any Unicode character, like icons and emoticons ;-)

Feb. 11, 2017

Re: [Pharo-users] About asSymbol message , some questions in my mind

by Denis Kudriashov

2017-02-11 8:51 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > The concept of 'meaning' is defined by the user, the usage, not by the > Symbol itself. A Symbol with a space cannot be a selector (message/method) > name But it could be: Point methodDict at: #'name with space' put: Point>>#x. 2@3 perform: #'name with space' "==> 2" Only problem that we could not use them with normal syntax

Feb. 11, 2017

Re: [Pharo-users] Unable to find the compiler

by serge.stinckwich＠gmail.com

You should replace also NameOfsubclass with MyCounter. EnvoyÃ© de mon iPhone > Le 11 fÃ©vr. 2017 Ã 00:32, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> a Ã©crit : > >> On 10/02/2017 23:58, Mark Neagu wrote: >> Hi, >> >> I'm starting my first exrcise in Pharo Mooc. I just wrote the definition of MyCounter (picture 1) and had to compile it by selecting the accept menu item (picture 2). >> > > Hi, > > You did a left click on what we call the "world" (the background of > Pharo). To get the right menu you need to do a *right* click on the > *code panel*. (See: https://puu.sh/tXu99/f11df69e74.png) > > But if you keep using Pharo you'll end up using the shortcut that is: > CMD + S or CTRL + S depending on the OS :) > > >> But I can't find any menu, so i can't compile MyCounter. >> >> Could you help me please? >> >> Regards, >> Mark >> > > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Feb. 11, 2017

Re: [Pharo-users] About asSymbol message , some questions in my mind

by Sven Van Caekenberghe

> On 11 Feb 2017, at 09:41, lb <liangbing64(a)126.com> wrote: > > Thank you, Sven > gradually clear. > 1. Symbol as String subclass, only guarantees a symbol object only one in system, use ==; > 2. keywords (selector name method name) are spectial symbols, without space or forbided characters; > 3. perform: aSymbol, means perform: aKeyword, > Should we add asKeyword to String, > let > perform: aString asKeyword > not > perform: aString asSymbol ? Good point, there has been discussion about a Selector class in the past, but I think the conclusion was, more or less, that it was not worth it (too much work/complexity for little gain). > Regards! > > Bing Liang > > At 2017-02-11 15:51:49, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: > >Hi Bing, > > > >Yes, any character is allowed in a Symbol. There is even special syntax that allows such Symbols to be represented literally. > > > >'a b' asSymbol. > > > > => #'a b' > > > >Although it might be confusing, I don't see any problem. > > > >The concept of 'meaning' is defined by the user, the usage, not by the Symbol itself. A Symbol with a space cannot be a selector (message/method) name, but that does not mean a Symbol with a space could not be useful in some other context. > > > >Regards, > > > >Sven > > > >> On 11 Feb 2017, at 05:56, lb <liangbing64(a)126.com> wrote: > >> > >> Hi, > >> I know Symbol is subclass of String. > >> Any string object can become symbol object by sending 'asSymbol' message.. > >> I think symbol must has its meaning in comon use, so the symbol should be composed of alphabet or number âwithout spaceâ. > >> > >> BUT There are not compliant below > >> 1. ' ' asSymbol >>>> no meaning > >> 2. '$%%&' asSymbol >>>> no meaning > >> 3. 'sign' asSymbol = 'sign ' asSymbol >>> false because of space. > >> 3. ' one two three ' asSymbol >>> I think It should become three symbols = #one, #two, #three > >> > >> > >> Mybe my understanding is wrong. > >> > >> Bing Liang > >> > >> > > > > >

Feb. 11, 2017