- Pharo-users - lists.pharo.org

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

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 12/02/17 09:19, stepharong wrote: > Hi offray > > I generate all my web page and cv with Citezen. > Can you tell > > which version of citezen? The one provided by ConfigurationOfCitezen (StephaneDucasse.137) > how you load it? From the spotter, so I imagine is reading the Pharo catalog. > which version of Pharo Pharo5.0 Latest update: #50761 > the expressions you executed? > I ran the expression on CZBibTest. After applying the fix proposed by Cyril on Citezen-Redenring (StephaneDucasse.42), the test went all green. So it seems a matter of replacing #allMethodsInCategory by #allSelectorsInProtocol Thanks, Offray > Stef > >> 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. 12, 2017

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

by Offray Vladimir Luna CÃ¡rdenas

My user account is Offray ( http://smalltalkhub.com/#!/~Offray ). I'm using the Citizen version provided by ConfigurationOfCitezen (StephaneDucasse.137). Thanks, Offray On 12/02/17 09:30, stepharong wrote: > what is your account on smalltalkhub? > > On Sun, 12 Feb 2017 00:52:10 +0100, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: > >> 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. 12, 2017

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

by stepharong

what is your account on smalltalkhub? On Sun, 12 Feb 2017 00:52:10 +0100, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > 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 >> >> >> > > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 12, 2017

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

by stepharong

On which version are you working? I should add an inbox to citezen (waiting to migrate to github). > 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 >> >> >> > > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 12, 2017

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

by stepharong

> Hi, > > would it make sense to take configurations from metarepos instead > directly from the source? I do not think so but if people show me otherwise I could follow that. Usually I have a conf in my repo referencing other repo and not the meta one Then I push in the meta just to config. > > And more imporantly: would be considered bad practice for users to do it > right now? > > E.g. > > spec > project: 'Magritte' > with: [ spec > className: #ConfigurationOfMagritte3; > versionString: #stable; > repository: > 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ]. > > v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' > > > pros: > * the (e.g. Magritte) developer can freely change platforms > * the ConfigurationOf could differ between various MetaRepo versions > (combined with git it could reduce their complexity) > * users do not have to think about where is the canonical repo (I've > seen project that had copies on SS, STHub, GitHub, and a custom location > -_-) > > cons: > * the ConfigurationOf could differ between various MetaRepo versions (if > the code is compatible, then two repos have to be updated > > Any thoughts? > > Peter > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 12, 2017

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

by stepharong

Hi offray I generate all my web page and cv with Citezen. Can you tell which version of citezen? how you load it? which version of Pharo the expressions you executed? Stef > 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 > > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 12, 2017

Re: [Pharo-users] Depending on MetaRepo instead of the target repo

by Stephan Eggermont

On 12/02/17 13:03, Peter Uhnak wrote: > would it make sense to take configurations from metarepos instead directly from the source? Not really. They are not kept exactly up-to-date in practice, and having one for each Pharo version is also kind of a bad practice. What is missing is some pushing mechanism that makes sure that configurations from the source repo get promoted to the metarepo when they pass some ci (smoke) tests. Stephan

Feb. 12, 2017

Depending on MetaRepo instead of the target repo

by Peter Uhnak

Hi, would it make sense to take configurations from metarepos instead directly from the source? And more imporantly: would be considered bad practice for users to do it right now? E.g. spec project: 'Magritte' with: [ spec className: #ConfigurationOfMagritte3; versionString: #stable; repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main/' ]. v. repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' pros: * the (e.g. Magritte) developer can freely change platforms * the ConfigurationOf could differ between various MetaRepo versions (combined with git it could reduce their complexity) * users do not have to think about where is the canonical repo (I've seen project that had copies on SS, STHub, GitHub, and a custom location -_-) cons: * the ConfigurationOf could differ between various MetaRepo versions (if the code is compatible, then two repos have to be updated Any thoughts? Peter

Feb. 12, 2017

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

by Ben Coman

On Sun, Feb 12, 2017 at 10:54 AM, lb <liangbing64(a)126.com> wrote: > 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. What is the higher level use case? For example, are you getting input from a user that you evaluate as a command in some kind of Domain Specific Language? In such a case you may be better to validate the command has no spaces closer to the UI? > > asMessage is better than asSymbol. If you don't get community support for this, you can start extending String like this for your own projects and later promote your concrete experience with it. cheers -ben > > 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

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