October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] execute a code block at a given time in pharo ?

by Daniel BLANC

Hi All, Sorry for the late answer, I've been swallowed by a vortex of "too much work at my day job". Regarding the magical power of smalltalk, I definitely agree with that. I've been playing with different programming languages for 30 years now, and smalltalk programming is so refreshing, it's almost like manipulating real physical objects, the process of building an app feels way more creative this way. Regarding my quick hack for managing the wifi at home, unfortunately there is not so much smalltalk magic involved. Pharo is just used as a UI to launch shell scripts on a linux server. This server is inbetween a wifi access point and the ISP router. So, as you probably have guessed, all the wifi traffic goes trough this server, then it's easy to use the linux firewall (iptable) to allow/deny traffic. I'll continue playing/hacking on this small app and I'll publish the end result. Thanks All, Daniel On Sun, Sep 17, 2017 at 7:18 PM Ben Coman <btc(a)openinworld.com> wrote: > On Sun, Sep 17, 2017 at 3:59 PM, Daniel BLANC <daniel.blanc(a)gmail.com> > wrote: > > Thanks Stef, this app is just a quick hack > > Quick hacks are still often interesting reading and useful starting > points for others. > I've often thought of doing something like this for my kids but never > got around to it. > > > but I already can stop the wifi from my phone > > I'm interested to know what you use for that also. > > cheers -ben > >

Oct. 3, 2017

Re: [Pharo-users] Iceberg and proxy

by Vitor Medina Cruz

Couldn't figure out how to configure a LGitFetchOptionswith a LGitProxyOptions accepting one of the auto/none/specified from LGitProxyTypeEnum. Can you provide an example? On Tue, Oct 3, 2017 at 1:06 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I know, but a LGitProxyOptions accepts one. > > On Tue, Oct 3, 2017 at 5:57 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> Nope, auto/none/specified returned objects are not compatible to the >> expected one received by prim_proxy_opts: >> >> On Tue, Oct 3, 2017 at 11:16 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Check that LGitFetchOptions has a pair of accessors prim_proxy_opts. >>> Maybe you can configure it with a LGitProxyTypeEnum which has values >>> auto/none/specified? >>> >>> On Tue, Oct 3, 2017 at 3:52 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>> wrote: >>> >>>> 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> >>>>> >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> 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] Iceberg and proxy

by Guillermo Polito

I know, but a LGitProxyOptions accepts one. On Tue, Oct 3, 2017 at 5:57 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Nope, auto/none/specified returned objects are not compatible to the > expected one received by prim_proxy_opts: > > On Tue, Oct 3, 2017 at 11:16 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Check that LGitFetchOptions has a pair of accessors prim_proxy_opts. >> Maybe you can configure it with a LGitProxyTypeEnum which has values >> auto/none/specified? >> >> On Tue, Oct 3, 2017 at 3:52 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >> wrote: >> >>> 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> >>>> >>> >>> >> >> >> -- >> >> >> >> 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

Nope, auto/none/specified returned objects are not compatible to the expected one received by prim_proxy_opts: On Tue, Oct 3, 2017 at 11:16 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Check that LGitFetchOptions has a pair of accessors prim_proxy_opts. Maybe > you can configure it with a LGitProxyTypeEnum which has values > auto/none/specified? > > On Tue, Oct 3, 2017 at 3:52 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> 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> >>> >> >> > > > -- > > > > 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] "Leaking" CommandLineHandler when running headless image

by Guillermo Polito

Yes, that's the issue. I'm still convinced about that :) On Tue, Sep 19, 2017 at 3:36 PM, Tim Mackinnon <tim(a)testit.works> wrote: > There was a long post from Guille about how to sort this. It had to do > with altering the priority of shutdown code - I'm not sure if we resolved > it, but we should go back and see as it was well reasoned. > > Tim > > Sent from my iPhone > > On 19 Sep 2017, at 14:20, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi. > > It is probably related to issue 20309 > <https://pharo.fogbugz.com/f/cases/20309/Startup-should-run-always-in-a-fres…> > > 2017-09-19 15:02 GMT+02:00 Holger Freyther <holger(a)freyther.de>: > >> Hi, >> >> I am currently trying to run one of my images as non-root and related to >> that look into keeping changes in a different directory or not writing them >> at all. While looking at a write failure I saw some paths being logged that >> I used during CI to load code and should have been GCed. >> >> >> Observation: >> >> >> Pharo --headless My.image eval "Smalltalk garbageCollect. >> CommandLineHandler allSubInstances size" >> 84 >> >> Pharo --headfull My.image eval "Smalltalk garbageCollect. >> CommandLineHandler allSubInstances size" >> 2 >> >> >> As part of the CommandLineHandler allSubInstances there are eight >> LoadUpdatesCommandLineHandler still active. I would assume that a full GC >> should have collected them by now (some of them being created in May). In a >> headfull image they disappear quickly >> >> I varied the execution a bit: >> >> Pharo --headless RoamingHub.image eval --no-quit "[ Smalltalk >> garbageCollect. FileStream stdout print: CommandLineHandler allSubInstances >> size; lf. Smalltalk snapshot: false andQuit: true] fork" >> 0 >> >> >> Hypothesis: >> >> >> * Command line handlers call >>#snapshot:andQuit:. >> * Image resumes in this process >> * New session created >> * Command line handlers execute >> * Calls snapshot:andQuit: >> * Image resumes.. >> * New session created >> * Command line handlers execute >> ... >> >> >> Can this be true? I think the proposal to start the image differently >> would help here? Any comments/ideas? >> >> holger >> > > -- 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] Reading a text file line by line

by Sven Van Caekenberghe

> On 3 Oct 2017, at 10:53, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Yes, in my todo, but changing FileReference like that will break a lot of backwards compatibility :) Yes it will. I have said this before: the problem is that the current stream API is much too wide, we need to trim it to something closer to what a stream is (and not assume that a stream always lives on top of a collection). We have compassable streams now, they work well. But they cannot implement the full API (since they are not streaming over collections). The biggest issue are the positioning message (like #skip: and #position:) which assume you known where you are and can move around at will, which is not possible for a real, indefinite stream. > On Mon, Oct 2, 2017 at 10:22 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Yes this is why we should continue to clean and remove cruft. Now I > remember that guille did that for File. > > Stef > > On Mon, Oct 2, 2017 at 3:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > If you do > > > > (File named: '/tmp/lines.txt') readStream[Do:] > > > > you seem to get a binary stream (this is the new implementation I guess), when you go via FileReference you get a character stream (but that are old ones). > > > > I know, very confusing. We're always in the midst of transitions. > > > >> On 2 Oct 2017, at 15:17, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >> > >> Sven I do not see the binary stream. Is it ZnCharacterReadStream? > >> > >> Stef > >> > >> On Mon, Oct 2, 2017 at 1:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> Hi, > >>> > >>>> On 2 Oct 2017, at 13:07, Dirk Olmes <dirk(a)xanthippe.ping.de> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I'm trying to get started with Pharo doing something really simple - at > >>>> least that's what I thought ... I'm trying to read a text file line by line. > >>>> > >>>> If I use File named: '/tmp/linex.txt' readStream nextLine I'll get a > >>>> debugger telling me that BinaryFileStream does not understand nextLine. > >>>> > >>>> Now I've tried my best to find a stream that may be reading plain text > >>>> lines but to no avail ... > >>>> > >>>> Help! > >>>> > >>>> -dirk > >>> > >>> $ cat > /tmp/lines.txt > >>> one > >>> two > >>> three > >>> > >>> (FileLocator temp / 'lines.txt') contents lines. > >>> > >>> '/tmp/lines.txt' asFileReference contents lines. > >>> > >>> '/tmp/lines.txt' asFileReference readStreamDo: [ :in | > >>> Array streamContents: [ :out | > >>> [ in atEnd ] whileFalse: [ out nextPut: in nextLine ] ] ]. > >>> > >>> (File named: '/tmp/lines.txt') readStreamDo: [ :in | > >>> | characterStream | > >>> characterStream := ZnCharacterReadStream on: in. > >>> Array streamContents: [ :out | > >>> [ characterStream atEnd ] whileFalse: [ out nextPut: characterStream nextLine ] ] ]. > >>> > >>> They all return #('one' 'two' 'three'). > >>> > >>> In the last, more complex example, you first get a binary stream (and a 'line' is a character based concept), so wrapping the binary stream in a character read stream (which does know about lines) solves the problem. > >>> > >>> HTH, > >>> > >>> Sven > >> > > > > > > > > > -- > > 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 > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

Oct. 3, 2017

Re: [Pharo-users] Iceberg and proxy

by Guillermo Polito

Check that LGitFetchOptions has a pair of accessors prim_proxy_opts. Maybe you can configure it with a LGitProxyTypeEnum which has values auto/none/specified? On Tue, Oct 3, 2017 at 3:52 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > 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> >> > > -- 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] 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