- Pharo-users - lists.pharo.org

Re: [Pharo-users] Equals and HashCode Builder

by Denis Kudriashov

2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz(a)gmail.com>: > >> I am sorry, not species, but #isKindOf istead of #= to compare classes. >> > > It is bad idea. #= should be transitive. > Oh, I used wrong word, shame on me :). I tried to say commutative. > How you will generate it with isKindOf: logic? You need to know common > parent. > > Also I not remember cases where I was needed two instances of different > classes to be equal. > And I can imaging the problems which it will lead to. > > >> >> On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> 2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>> >>>> >>>> Two questions/comments about the generated code: >>>> 1. #= >>>> ... >>>> self class = anObject class "should compare #species instead?" >>>> ifFalse: [ ^ false ]. >>>> ... >>>> Typically, I've seen #species instead of #class in the guard statement. >>>> Should we change it to that? >>>> >>> >>> I doubt that it is important for domain classes. Because I never saw the >>> user of #species which is not a kind of Collection. And for collections >>> this refactoring is not valid anyway. >>> >>> >>>> >>>> >>>> 2. #hash >>>> ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) >>>> Is this implementation always safe? It's what I usually hand roll based >>>> on >>>> what I've seen, but Andres Valloud wrote a whole (large) book on >>>> hashing, so >>>> I've always wondered if I was missing somethingâ¦ >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>> >>>> >>> >> >

Oct. 3, 2017

Re: [Pharo-users] Iceberg and proxy

by Vitor Medina Cruz

I got to this point: remote_fetch: remote refspecs: refspecs opts: opts reflog_message: reflog_message ^ self call: #(LGitReturnCodeEnum git_remote_fetch #(self , void * refspecs , LGitFetchOptions * opts , String reflog_message)) options: #(optCoerceNilToNull) This seams like a call to a native C code. The opts has an authentication callback, which should be called, but it is not. Any leads on what I can do from here to figure out what is happening? On Tue, Oct 3, 2017 at 9:09 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Looks like it's an iceberg/libgit problem. We should set the proxy to > libgit :) > > https://libgit2.github.com/libgit2/#HEAD/search/proxy > > On Tue, Oct 3, 2017 at 2:03 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> Yes, I already done that. I am behind a NTLM proxy, so I set up a cntlm >> proxy and configured Pharo settings accordingly. It is working because I >> can use Zinc directly, but Iceberg cannot pull/push. I tried the same at >> home without a proxy and I could not pull/push either, so it probably has >> nothing to do with the proxy. >> >> I will investigate moreâ¦. >> >> On Tue, Oct 3, 2017 at 5:31 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> You should probably set the proxy in the Pharo settings. Pharo does not >>> recognize the system's proxy (so far). >>> >>> Could you try with that? >>> >>> Guille >>> >>> On Mon, Oct 2, 2017 at 4:35 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>> wrote: >>> >>>> git push via command line works fine. When I try to pull, for example, >>>> from Iceberg it says "a connection with the server cannot be estabilished". >>>> I am using a cntlm bypass proxy with loggin on, and Iceberg is using it, >>>> but it fails while normal Zinc usage is ok. >>>> >>>> I will try to understand better what is happening.... >>>> >>>> On Mon, Oct 2, 2017 at 3:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>>> wrote: >>>> >>>>> hi, >>>>> >>>>> if you have the ssh port restricted, you need to use one that is >>>>> notâ¦but then, is not clear how it will work on server side. >>>>> can you try if you can do command line git push in your project? >>>>> >>>>> Esteban >>>>> >>>>> On 2 Oct 2017, at 19:57, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>>>> wrote: >>>>> >>>>> Hello! >>>>> >>>>> Iceberg donât work behind a proxy? I have made proper proxy >>>>> configuration, if I use Zinc, for example, the proxy information is used, >>>>> but that donât seems to be the case for Iceberg. >>>>> >>>>> Regards, >>>>> >>>>> Vito >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Oct. 3, 2017

Re: [Pharo-users] why are Help topics in the meta-side

by Esteban A. Maringolo

2017-10-03 10:14 GMT-03:00 H. Hirzel <hannes.hirzel(a)gmail.com>: > In the end it is probably a matter of conventions. > > Instruction how to construct something (e.g. Spec) Conventions and history, which maybe are the same thing :) VisualSmalltalk/VisualWorks, Dolphin, VAST keep the definition of the windows/panes in the class side, whether they're Smalltalk expressions or binary/literal arrays (Dolphin). In the case of Dolphin each "class method" defines a "resource" you can have more than one layout for the same class, so you can have a "read only" view (resource) and an "editable" view sharing the same instance behavior. Also, having it class side you can reference it/preview (rendered) from other views without having to instantiate them, which might require having a valid model, etc. > / configuration information / descriptions > / help information / examples are kept on the class side. In fact I don't like that Magritte moved the descriptions from class to instance side. My two cents on this. Regards! Esteban A. Maringolo

Oct. 3, 2017

Re: [Pharo-users] why are Help topics in the meta-side

by H. Hirzel

In the end it is probably a matter of conventions. Instruction how to construct something (e.g. Spec) / configuration information / descriptions / help information / examples are kept on the class side. HH On 10/3/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > The information for a help topic on the class side is used to create a > help instance. > > Even if I technically create several instances of a particular help > topic with information taken from the class side conceptually I have > only _one_ help topic. The instances all share exactly the same > content. > > Maybe the idea of 'Uniclass' (Etoys / Squeak') though not exactly the > same may help. > "UniClasses are classes for the instance specific behavior of just one > instance." > http://wiki.squeak.org/squeak/2402 > > In Smalltalk I always have to deal with classes. A class is an object > as well. Good to keep information for cases where I do not care to > have different instances with different state. > > HTH > > Hannes > > On 10/3/17, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> On Tue, Oct 3, 2017 at 2:17 PM, H. Hirzel <hannes.hirzel(a)gmail.com> >> wrote: >> >>> This is as if you would ask >>> >>> why are specs on the class side? >>> >> >> I can certainly ask that, and there's in fact no reason why it would have >> to be there (because when the layout is being retrieved, the instance is >> already available). >> >> >>> You may actually see Help information as 'meta information'. It is >>> information about .... >>> >> >> If you put it on the class-side of the class that it is about then I >> would >> agree. But that is not the case here. The object is the content, not >> about >> the content. >> >> >>> >>> The content is only needed once per topic. No different instances of the >>> same topic. >>> >> >> This is not actually true; the topic is instantiated anew for every help >> browser opened (and every time browser is opened). >> >> And in fact the CustomHelp subclass is recasted to HelpTopic at runtime, >> which makes the entire class quite pointless; which is what I don't >> understand. >> >> Peter >> >

Oct. 3, 2017

Re: [Pharo-users] why are Help topics in the meta-side

by H. Hirzel

The information for a help topic on the class side is used to create a help instance. Even if I technically create several instances of a particular help topic with information taken from the class side conceptually I have only _one_ help topic. The instances all share exactly the same content. Maybe the idea of 'Uniclass' (Etoys / Squeak') though not exactly the same may help. "UniClasses are classes for the instance specific behavior of just one instance." http://wiki.squeak.org/squeak/2402 In Smalltalk I always have to deal with classes. A class is an object as well. Good to keep information for cases where I do not care to have different instances with different state. HTH Hannes On 10/3/17, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > On Tue, Oct 3, 2017 at 2:17 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > >> This is as if you would ask >> >> why are specs on the class side? >> > > I can certainly ask that, and there's in fact no reason why it would have > to be there (because when the layout is being retrieved, the instance is > already available). > > >> You may actually see Help information as 'meta information'. It is >> information about .... >> > > If you put it on the class-side of the class that it is about then I would > agree. But that is not the case here. The object is the content, not about > the content. > > >> >> The content is only needed once per topic. No different instances of the >> same topic. >> > > This is not actually true; the topic is instantiated anew for every help > browser opened (and every time browser is opened). > > And in fact the CustomHelp subclass is recasted to HelpTopic at runtime, > which makes the entire class quite pointless; which is what I don't > understand. > > Peter >

Oct. 3, 2017

Re: [Pharo-users] why are Help topics in the meta-side

by Peter UhnÃ¡k

On Tue, Oct 3, 2017 at 2:17 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > This is as if you would ask > > why are specs on the class side? > I can certainly ask that, and there's in fact no reason why it would have to be there (because when the layout is being retrieved, the instance is already available). > You may actually see Help information as 'meta information'. It is > information about .... > If you put it on the class-side of the class that it is about then I would agree. But that is not the case here. The object is the content, not about the content. > > The content is only needed once per topic. No different instances of the > same topic. > This is not actually true; the topic is instantiated anew for every help browser opened (and every time browser is opened). And in fact the CustomHelp subclass is recasted to HelpTopic at runtime, which makes the entire class quite pointless; which is what I don't understand. Peter

Oct. 3, 2017

Re: [Pharo-users] why are Help topics in the meta-side

by H. Hirzel

This is as if you would ask why are specs on the class side? You may actually see Help information as 'meta information'. It is information about .... The content is only needed once per topic. No different instances of the same topic. --Hannes On 10/3/17, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > All help topics (subclasses of CustomHelp) have all the content on the > class-side. > > This seems very weird to me, because the class-side should about managing > the meta, not containing the content itself. > > It feels weird. > > Peter >

Oct. 3, 2017

Re: [Pharo-users] Iceberg and proxy

by Guillermo Polito

Looks like it's an iceberg/libgit problem. We should set the proxy to libgit :) https://libgit2.github.com/libgit2/#HEAD/search/proxy On Tue, Oct 3, 2017 at 2:03 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Yes, I already done that. I am behind a NTLM proxy, so I set up a cntlm > proxy and configured Pharo settings accordingly. It is working because I > can use Zinc directly, but Iceberg cannot pull/push. I tried the same at > home without a proxy and I could not pull/push either, so it probably has > nothing to do with the proxy. > > I will investigate moreâ¦. > > On Tue, Oct 3, 2017 at 5:31 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> You should probably set the proxy in the Pharo settings. Pharo does not >> recognize the system's proxy (so far). >> >> Could you try with that? >> >> Guille >> >> On Mon, Oct 2, 2017 at 4:35 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >> wrote: >> >>> git push via command line works fine. When I try to pull, for example, >>> from Iceberg it says "a connection with the server cannot be estabilished". >>> I am using a cntlm bypass proxy with loggin on, and Iceberg is using it, >>> but it fails while normal Zinc usage is ok. >>> >>> I will try to understand better what is happening.... >>> >>> On Mon, Oct 2, 2017 at 3:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>>> hi, >>>> >>>> if you have the ssh port restricted, you need to use one that is >>>> notâ¦but then, is not clear how it will work on server side. >>>> can you try if you can do command line git push in your project? >>>> >>>> Esteban >>>> >>>> On 2 Oct 2017, at 19:57, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>>> wrote: >>>> >>>> Hello! >>>> >>>> Iceberg donât work behind a proxy? I have made proper proxy >>>> configuration, if I use Zinc, for example, the proxy information is used, >>>> but that donât seems to be the case for Iceberg. >>>> >>>> Regards, >>>> >>>> Vito >>>> >>>> >>>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 3, 2017

Re: [Pharo-users] Iceberg and proxy

by Vitor Medina Cruz

Yes, I already done that. I am behind a NTLM proxy, so I set up a cntlm proxy and configured Pharo settings accordingly. It is working because I can use Zinc directly, but Iceberg cannot pull/push. I tried the same at home without a proxy and I could not pull/push either, so it probably has nothing to do with the proxy. I will investigate moreâ¦. On Tue, Oct 3, 2017 at 5:31 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > You should probably set the proxy in the Pharo settings. Pharo does not > recognize the system's proxy (so far). > > Could you try with that? > > Guille > > On Mon, Oct 2, 2017 at 4:35 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> git push via command line works fine. When I try to pull, for example, >> from Iceberg it says "a connection with the server cannot be estabilished". >> I am using a cntlm bypass proxy with loggin on, and Iceberg is using it, >> but it fails while normal Zinc usage is ok. >> >> I will try to understand better what is happening.... >> >> On Mon, Oct 2, 2017 at 3:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> hi, >>> >>> if you have the ssh port restricted, you need to use one that is notâ¦but >>> then, is not clear how it will work on server side. >>> can you try if you can do command line git push in your project? >>> >>> Esteban >>> >>> On 2 Oct 2017, at 19:57, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: >>> >>> Hello! >>> >>> Iceberg donât work behind a proxy? I have made proper proxy >>> configuration, if I use Zinc, for example, the proxy information is used, >>> but that donât seems to be the case for Iceberg. >>> >>> Regards, >>> >>> Vito >>> >>> >>> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Oct. 3, 2017

why are Help topics in the meta-side

by Peter UhnÃ¡k

All help topics (subclasses of CustomHelp) have all the content on the class-side. This seems very weird to me, because the class-side should about managing the meta, not containing the content itself. It feels weird. Peter

Oct. 3, 2017