September 2017 - Pharo-users

Re: [Pharo-users] Force headless mode

by Sven Van Caekenberghe

> On 26 Sep 2017, at 18:06, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Sep 26, 2017 at 5:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> it is not. >> specially on windows. >> >> vm handles the creation of host window and you will always have one. >> >> nowâ¦ if you wait one week, I will have ready the (experimental) real headless VMs. In my tests, they are working fine but we will still need to work when we want to actually start a world windowâ¦ but thatâs another story ;) >> > > I don't think we can wait Pharo 7 before doing this task. But I can > still try it when you're done. > > With this, will it be possible to totally disable the non headless > mode in production? Why not do as follows: (1) add some startup code inside the image that tests if the image is running headless, if not exit (2) remove some of the command line handlers (especially the ones that execute or load code) Problem is that you will lock yourself out as well ;-) >> Esteban >> >> >> > > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Sept. 26, 2017

Re: [Pharo-users] About encoding

by Sven Van Caekenberghe

> On 26 Sep 2017, at 18:09, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Here is a script that should work to convert from latin1 to utf-8. > Thanks to your book and trial and error. > > | str wstr | > str := ('listeDeMotsFrancaisFrGut.txt' asFileReference readStreamDo: [ :in | > (ZnCharacterReadStream on: in binary encoding: #latin1) > upToEnd ]) lines. > > 'listeDeMotsFrancaisFrGutUTF8.txt' asFileReference writeStreamDo: [ :out | > wstr := (ZnCharacterWriteStream on: out binary encoding: #utf8). > str do: [ :each | wstr nextPutAll: each. wstr crlf. ]. > ]. Yes, that is correct (and using the newer encoders in both directions) > On Tue, Sep 26, 2017 at 6:01 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Now inspecting the file containent opens gtinspector and freezes Pharo :( >> I think that I will remove this part of my book. >> It is simpler. >> >> On Tue, Sep 26, 2017 at 5:53 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> I'm reading your chapter :) >>> Now I understand the file I found is totally bogus :) >>> But the first one I found is indeed encoded in latin1. >>> So I'm trying to convert it. >>> >>> >>> >>> >>> On Tue, Sep 26, 2017 at 5:40 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>>>> Any chance you can point me to the original file ? >>>> >>>> No they removed it >>>> May be I could try to convert it to utf-8 (I do not know how to do it) >>>> >>>>> The file is indeed in Latin1 encoded, but GitHub serves it as UTF-8 (it did not change the contents, but the meta data). >>>> >>>> Ok I see the problem >>>>> >>>>> The default encoder option only works when the server says nothing, it does not override what the server says. >>>> >>>> Ah ok. >>>> >>>>> The only way to read it, is by reading it binary (which basically ignores the meta data) and then convert it manually: >>>>> >>>>> (ZnCharacterEncoder latin1 decodeBytes: >>>>> (ZnClient new >>>>> beBinary; >>>>> get: 'https://raw.githubusercontent.com/SquareBracketAssociates/LearningOOPWithPh…')) lines. >>>>> >>>>> But this is very ugly. >>>>> >>>>> Best convert the original file to UTF-8 before uploading to GitHub. >>>> >>>> OK I will try to leanr how to do it. >>>> >>>> >>>>> >>>>> Sven >>>>> >>>>> >>>>> >

Sept. 26, 2017

Re: [Pharo-users] About encoding

by Stephane Ducasse

Here is a script that should work to convert from latin1 to utf-8. Thanks to your book and trial and error. | str wstr | str := ('listeDeMotsFrancaisFrGut.txt' asFileReference readStreamDo: [ :in | (ZnCharacterReadStream on: in binary encoding: #latin1) upToEnd ]) lines. 'listeDeMotsFrancaisFrGutUTF8.txt' asFileReference writeStreamDo: [ :out | wstr := (ZnCharacterWriteStream on: out binary encoding: #utf8). str do: [ :each | wstr nextPutAll: each. wstr crlf. ]. ]. On Tue, Sep 26, 2017 at 6:01 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Now inspecting the file containent opens gtinspector and freezes Pharo :( > I think that I will remove this part of my book. > It is simpler. > > On Tue, Sep 26, 2017 at 5:53 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> I'm reading your chapter :) >> Now I understand the file I found is totally bogus :) >> But the first one I found is indeed encoded in latin1. >> So I'm trying to convert it. >> >> >> >> >> On Tue, Sep 26, 2017 at 5:40 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>>> Any chance you can point me to the original file ? >>> >>> No they removed it >>> May be I could try to convert it to utf-8 (I do not know how to do it) >>> >>>> The file is indeed in Latin1 encoded, but GitHub serves it as UTF-8 (it did not change the contents, but the meta data). >>> >>> Ok I see the problem >>>> >>>> The default encoder option only works when the server says nothing, it does not override what the server says. >>> >>> Ah ok. >>> >>>> The only way to read it, is by reading it binary (which basically ignores the meta data) and then convert it manually: >>>> >>>> (ZnCharacterEncoder latin1 decodeBytes: >>>> (ZnClient new >>>> beBinary; >>>> get: 'https://raw.githubusercontent.com/SquareBracketAssociates/LearningOOPWithPh…')) lines. >>>> >>>> But this is very ugly. >>>> >>>> Best convert the original file to UTF-8 before uploading to GitHub. >>> >>> OK I will try to leanr how to do it. >>> >>> >>>> >>>> Sven >>>> >>>> >>>>

Sept. 26, 2017

Re: [Pharo-users] Pharo 7 license question

by Jimmie Houchin

On 09/26/2017 06:09 AM, Ben Coman wrote: > > > On Mon, Sep 25, 2017 at 9:43 PM, Jimmie Houchin <jlhouchin(a)gmail.com > <mailto:jlhouchin@gmail.com>> wrote: > > Hello, thanks for the reply. > > I have thought about recursive and unfortunately it is not in my > opinion an adequate or equivalent substitute. It may be > inoffensive, but it is not accurate in conveying those properties > or characteristics of the GPL. Something that is recursive > generally makes repeated calls to itself. It is neatly contained > and does not propagate outside of itself. Calling a recursive > method does not make the call chain all the way up to main > recursive. The recursive method does its recursion and generally > returns its result back to the caller, ending the recursion. The > only thing the caller receives is the results, not the recursion. > > There are many positive cultural references to something viral or > infect(ious). For something to go viral, depends on what that > something is. She has an infectious smile, or laugh. Even in > biology where we get the term viral. It is not absolutely or > always negative. There are things that scientist attempt to use > viral characteristics to do good things. Context is everything. > > There are no words a GPL proponent could provide which adequately > or otherwise describe the viral characteristic of the GPL that > would be considered positive by a GPL opponent. > > Back to context. > > To a GPL proponent, the viral nature of the GPL is considered a > positive and good thing. It is the primary reason to choose and > use the GPL. > > To the GPL opponent, the viral nature of the GPL is considered a > negative and bad thing. It is the primary reason to oppose and to > avoid using the GPL. > > Two side both viewing the same exact thing and understanding it > very differently. One positive, one negative. There is no positive > spin for this aspect of the GPL for someone wishing to avoid that > aspect. No matter what words are chosen. > > For the MIT/BSD person we don't necessarily care if you wish to > license your software under the GPL. What we care is that your > software is expressly and explicitly trying to override our > choices and compel us to become GPL. That is what we don't like. > The fact that GPL software is GPL software in perpetuity is okay. > Just leave us alone. But we know that is not how the GPL works. > > > A perspective occurred to me this morning. The original author of > GPL software is not bound by the GPL. > > > I think this thread has run its course for now, but just a quick > clarification here.Â The above is only true up until they accept the > first contribution from another party - so its not a good argument. > > cheers -ben Â . I agree that it has run its course. However, the original author still can do whatever they want with the code they wrote. They have copyright. But they can not undo what has been released. They cannot use any other contributors code without that code also affecting any of the other code they may have added to or modifications of the original. But the initial offering and any additions and modifications they do which does not other contributors GPLd code is still under their complete control to do as they wish. This is the only way anybody would be able to do dual licensing. As is the case in something like QT or other such projects. But anything they write which is without contributions is still totally within their control to do so as they please. And as I said, there are many projects who started out as GPL and switched to MIT. Yes, someone could still take what was released as GPL and keep it going. But it would then be competing with the MIT version. Nim and PicoLisp are two such projects that started as GPL and moved to MIT. They could even do so with contributed code if the contributors signed agreements assigning copyrights to the original author. Jimmie

Sept. 26, 2017

Re: [Pharo-users] Force headless mode

by Cyril Ferlicot

On Tue, Sep 26, 2017 at 5:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > it is not. > specially on windows. > > vm handles the creation of host window and you will always have one. > > nowâ¦ if you wait one week, I will have ready the (experimental) real headless VMs. In my tests, they are working fine but we will still need to work when we want to actually start a world windowâ¦ but thatâs another story ;) > I don't think we can wait Pharo 7 before doing this task. But I can still try it when you're done. With this, will it be possible to totally disable the non headless mode in production? > Esteban > > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Sept. 26, 2017

Re: [Pharo-users] About encoding

by Stephane Ducasse

Now inspecting the file containent opens gtinspector and freezes Pharo :( I think that I will remove this part of my book. It is simpler. On Tue, Sep 26, 2017 at 5:53 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I'm reading your chapter :) > Now I understand the file I found is totally bogus :) > But the first one I found is indeed encoded in latin1. > So I'm trying to convert it. > > > > > On Tue, Sep 26, 2017 at 5:40 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >>> Any chance you can point me to the original file ? >> >> No they removed it >> May be I could try to convert it to utf-8 (I do not know how to do it) >> >>> The file is indeed in Latin1 encoded, but GitHub serves it as UTF-8 (it did not change the contents, but the meta data). >> >> Ok I see the problem >>> >>> The default encoder option only works when the server says nothing, it does not override what the server says. >> >> Ah ok. >> >>> The only way to read it, is by reading it binary (which basically ignores the meta data) and then convert it manually: >>> >>> (ZnCharacterEncoder latin1 decodeBytes: >>> (ZnClient new >>> beBinary; >>> get: 'https://raw.githubusercontent.com/SquareBracketAssociates/LearningOOPWithPh…')) lines. >>> >>> But this is very ugly. >>> >>> Best convert the original file to UTF-8 before uploading to GitHub. >> >> OK I will try to leanr how to do it. >> >> >>> >>> Sven >>> >>> >>>

Sept. 26, 2017

Re: [Pharo-users] Force headless mode

by Esteban Lorenzano

> On 26 Sep 2017, at 16:49, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > > At Synectique we are working on the deployment of a web application > and we would like to force the headless mode. We tried to just > override the method SmalltalkImage>>#isHeadless to return true all the > time be it is not enough because the image is still opened. It is > probabaly the vm that open the window. > > I know we can add some arguments to the command line to open the image > as headless but we want to forbid the user to launch the image without > headless to protect the code. > > Is this possible? Do you have some pointers? it is not. specially on windows. vm handles the creation of host window and you will always have one. nowâ¦ if you wait one week, I will have ready the (experimental) real headless VMs. In my tests, they are working fine but we will still need to work when we want to actually start a world windowâ¦ but thatâs another story ;) Esteban > > Thanks in advance. > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France >

Sept. 26, 2017

Re: [Pharo-users] About encoding

by Stephane Ducasse

I'm reading your chapter :) Now I understand the file I found is totally bogus :) But the first one I found is indeed encoded in latin1. So I'm trying to convert it. On Tue, Sep 26, 2017 at 5:40 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Any chance you can point me to the original file ? > > No they removed it > May be I could try to convert it to utf-8 (I do not know how to do it) > >> The file is indeed in Latin1 encoded, but GitHub serves it as UTF-8 (it did not change the contents, but the meta data). > > Ok I see the problem >> >> The default encoder option only works when the server says nothing, it does not override what the server says. > > Ah ok. > >> The only way to read it, is by reading it binary (which basically ignores the meta data) and then convert it manually: >> >> (ZnCharacterEncoder latin1 decodeBytes: >> (ZnClient new >> beBinary; >> get: 'https://raw.githubusercontent.com/SquareBracketAssociates/LearningOOPWithPh…')) lines. >> >> But this is very ugly. >> >> Best convert the original file to UTF-8 before uploading to GitHub. > > OK I will try to leanr how to do it. > > >> >> Sven >> >> >>

Sept. 26, 2017

Re: [Pharo-users] Force headless mode

by Cyril Ferlicot

On Tue, Sep 26, 2017 at 5:13 PM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > Hi > > What about deploying a minimal image without UI ? > But, as you probably know, headless mode does not prevent to dump the code. > I just tried to build our tools on a minimal image but it crash when trying to load a github's project. I now added a piece of code to update Metacello to a newer version but it just do nothing without any log. I know there is still some way to get the code but this is the first step to build a real delivery image. > Christophe > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Sept. 26, 2017

Re: [Pharo-users] About encoding

by Sven Van Caekenberghe

You can convert it in Pharo, of course: (FileLocator desktop / 'mots.txt') writeStreamDo: [ :out | out << (ZnCharacterEncoder latin1 decodeBytes: (ZnClient new beBinary; get: 'https://raw.githubusercontent.com/SquareBracketAssociates/LearningOOPWithPh…')) ]. You just take the string as it is in Pharo and write it out to a file, it is by default utf-8 encoded. > On 26 Sep 2017, at 17:40, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >> Any chance you can point me to the original file ? > > No they removed it > May be I could try to convert it to utf-8 (I do not know how to do it) > >> The file is indeed in Latin1 encoded, but GitHub serves it as UTF-8 (it did not change the contents, but the meta data). > > Ok I see the problem >> >> The default encoder option only works when the server says nothing, it does not override what the server says. > > Ah ok. > >> The only way to read it, is by reading it binary (which basically ignores the meta data) and then convert it manually: >> >> (ZnCharacterEncoder latin1 decodeBytes: >> (ZnClient new >> beBinary; >> get: 'https://raw.githubusercontent.com/SquareBracketAssociates/LearningOOPWithPh…')) lines. >> >> But this is very ugly. >> >> Best convert the original file to UTF-8 before uploading to GitHub. > > OK I will try to leanr how to do it. > > >> >> Sven >> >> >> >

Sept. 26, 2017