September 2017 - Pharo-users

Re: [Pharo-users] Pharo 7 license question

by stephan

On 16-09-17 18:51, Peter UhnÃ¡k wrote: > This is the reason why LGPL exists. LGPL is not contagious. It is not clear that that would be the case with smalltalk. We tend to reuse by subclassing, and linking is not so well-defined. There is no license that has the same effect as LGPL has for c programs for smalltalk. Stephan

Sept. 17, 2017

Re: [Pharo-users] PlotMorph on Pharo 6.1

by Stephane Ducasse

Tx Stefan I was planning to do the same. On Sat, Sep 16, 2017 at 3:41 PM, stephan <stephan(a)stack.nl> wrote: > On 16-09-17 09:29, Stephane Ducasse wrote: >> >> I'm on 10.12.6. too >> I downloaded Pharo 32 using the link. >> And I loaded from Catalog and I cannot get the problem. >> May be there is a problem with a setting in the compiler. >> I will talk to the guys monday. > > > Meta6, 7 and PlotMorph repos > > Name: ConfigurationOfPlotMorph-StephanEggermont.6 > Author: StephanEggermont > Time: 16 September 2017, 3:39:18.049684 pm > UUID: 246e825f-b015-0d00-a8c8-7793003b8086 > Ancestors: ConfigurationOfPlotMorph-StephanEggermont.5 > > No longer assign to block parameters in Pharo 6 and 7 > > Name: PlotMorph-StephanEggermont.9 > Author: StephanEggermont > Time: 16 September 2017, 3:26:48.762733 pm > UUID: e138d932-b015-0d00-a8c9-885a003b8086 > Ancestors: PlotMorph-StephanEggermont.8 > > No longer assign to block parameters > >

Sept. 16, 2017

Re: [Pharo-users] Pharo 7 license question

by Peter UhnÃ¡k

> someone to get a reasonably definitive answer on this question? you would get that only from a copyright layer... and definitive answer only from a judge ;) I don't see how Pharo bootstrap changes anything. If you mean that you can now add library after bootstrap... well you can do that now already with any previous Pharo version. GPL is viral infection, so if you decide to bundle Pharo with your GPL-ed code, then the whole package will be terminally infected, including all the source code. Pharo or any other loaded libraries in the distro will be considered as GPL. Pharo is under MIT, so you can sublicense it, however if someone decided to contribute some code to your distribution (even if it was to Pharo), the contribution would be considered GPL and only the author would be able to put it to Pharo under the original MIT license. If you are wondering whether you can distribute Pharo with GPL code linked to it and keep the rest MIT, then the answer is no (and GPL v3 is particularly anal about this, as people are trying to work around it with v2). This is the reason why LGPL exists. LGPL is not contagious. But again, I don't see how Pharo bootstrap changes any of this. Peter On Sat, Sep 16, 2017 at 9:17 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I do not think that the bootstrap changed anything. :) > We will stay away from GPL. > May be you can talk to the people of the libraries you want to use and > see if they are interested in a dual license. > > Stef > > On Fri, Sep 15, 2017 at 10:49 PM, Jimmie Houchin <jlhouchin(a)gmail.com> > wrote: > > Hello, > > > > Pharo 7 to my understanding fundamentally changes Pharo. It is my > > understanding that Pharo 7 starts with a core Pharo kernel and like many > > languages out there, imports or adds code from a variety of external > sources > > to the image being built. > > > > With that understanding, I am curious if that would allow for inclusion > of a > > specific library/module to be licensed as GPL? And it not affect the > other > > code in the composed image? > > > > I am a big believer in the MIT/BSD license and not a big fan of the GPL. > > However, there is software out there that I have avoided looking at the > > source code or attempting to port it to Pharo because it is GPL. I would > > sincerely love if I could now port such a library and license it under > the > > GPL as required, and it not affect any other code outside of that > specific > > library. > > > > I am not a lawyer. Nor do I know any lawyers. Is is possible for someone > to > > get a reasonably definitive answer on this question? > > > > I am sure I am not the only one who has had this desire. I am also sure > that > > I am not the only one who will have this question in the future. So it > would > > be nice to have a proper legal response that could possibly be explicitly > > stated somewhere on the website or on an FAQ or something. > > > > Regardless of the answer, yes or no. It does need to be a settled issue > for > > Pharo. That way someone could know if GPL/LGPL or whatever software > could be > > in the catalog. > > > > Just wanted to put that out there to the community. I look forward to the > > answer, should one be or become available. > > > > Thanks. > > > > > > Jimmie > > > > > > > >

Sept. 16, 2017

Re: [Pharo-users] PlotMorph on Pharo 6.1

by stephan

On 16-09-17 09:29, Stephane Ducasse wrote: > I'm on 10.12.6. too > I downloaded Pharo 32 using the link. > And I loaded from Catalog and I cannot get the problem. > May be there is a problem with a setting in the compiler. > I will talk to the guys monday. Meta6, 7 and PlotMorph repos Name: ConfigurationOfPlotMorph-StephanEggermont.6 Author: StephanEggermont Time: 16 September 2017, 3:39:18.049684 pm UUID: 246e825f-b015-0d00-a8c8-7793003b8086 Ancestors: ConfigurationOfPlotMorph-StephanEggermont.5 No longer assign to block parameters in Pharo 6 and 7 Name: PlotMorph-StephanEggermont.9 Author: StephanEggermont Time: 16 September 2017, 3:26:48.762733 pm UUID: e138d932-b015-0d00-a8c9-885a003b8086 Ancestors: PlotMorph-StephanEggermont.8 No longer assign to block parameters

Sept. 16, 2017

Re: [Pharo-users] UFFI problem / doubt

by alvaro piorno

Hi Stephan, Thanks for your answer, i found the booklet, but it was a draft, so it was incomplete. An example of FFIOpaqueObject would be healpful, i think. Esteban already talked to me, and is helping me with this. What do you mean with "Chipmunk existing bindings" ?. 2017-09-16 4:42 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi alvaro > > Thanks for the question. If you have any suggestion for the booklet on > UFFI let us know. > I will let esteban anwser because I do not know. > BTW did you check the chipmunk existing bindings? > > Stef > > On Fri, Sep 15, 2017 at 3:42 PM, alvaro piorno > <alvaropiorno100(a)gmail.com> wrote: > > Hi everybody, iÂ´m using UnifiedFFI with Chipmunk2D library . > > I want to get a pointer to a C Structure (cpBody) and set a position to > it. > > I have a subClass of FFIOpaqueObject to handle pointer. > > > > This is the "new " ffiCall : > > self ffiCall: #(cpBody* cpBodyNew(cpFloat m, cpFloat i)) > > > > And this is a "seter" ffiCall: > > > > self ffiCall: #( void cpBodySetPosition( self, cpVect vector ) ). > > > > I`m not getting any "error" but the position is not updating. > > I tried the same using Chipmunk directly and it works, so there is a > problem > > with what i have in Pharo. > > Any suggestion? > > Thanks in advance. > > > > Alvaro Piorno > >

Sept. 16, 2017

Re: [Pharo-users] New chapter for coming book: Messages

by H. Hirzel

Stephane Thank you for the reminder in the chapter that classes are cheap! If I have a class hierarchy with 300 classes (for example builder classes) but they all implement just one method (#build) then that is not complex at all. Another thing: I assume you will have a chapter on visitors as well. Do you have an outline / draft for that? --Hannes On 9/11/17, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > tx for the feedback! > > > On Mon, Sep 11, 2017 at 1:18 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> Hello Stephane >> >> I like the emphasis of the chapter that implementing same selector >> several times at the proper place in a couple of classes is more >> important than to rely on inheritance. >> >> In particular the conclusion >> >> <citation> >> What is important to realise is that classes are cheap. It is better >> to write 5 little classes than a huge one. Some (even smart) people >> got confused by measuring complexity of a system using number of >> classes. Having many classes representing good abstractions with a >> single responsibility is much much better than having a single class >> exhibiting multiple responsibilities. >> </citation> >> >> Suggestion: put it into a 'Note' box. >> >> >> >> >> >> And replace >> >> 'got confused' >> >> with: >> >> 'get confused' >> >> >> >> >> >> >> >> Replace: >> >> Now the choices can be made over multiple tenth of classes. >> >> 'multiple tenth' is an uncommon expression >> >> Suggestion: >> Now the choices can be made over dozens of classes. >> >> >> >> >> >> >> However >> 'Sending a message is making a choice!' >> takes the view point of the mechanism which does the late binding. >> >> If I write >> >> aNode emitHTML: aStream >> >> I do not make the choice. There are different types of nodes and they >> all do the same in the sense that they produce HTML code. >> >> In any case to drive the point home more examples are needed. >> >> The Boolean example is the minimal example and as such is interesting. >> But it is a borderline case which just illustrates that Smalltalk goes >> a long way to implement the object and message pattern consistently. >> >> The Pillar example is fine but too terse. >> For people who already understand the issue just a reference is fine. >> But for people new to the concept of replacing a case statement with a >> class hierarchy it is too short. >> >> Elaborate! >> >> >> E.g. have a diagram for a subset of the hierarchy >> >> PRObject #(''properties'') >> PRDocumentItem #(''counter'') >> PRDocumentGroup #(''children'') >> PRDocument #() >> PRHeader #(''level'') >> PRList #() >> PROrderedList #() >> PRUnorderedList #() >> PRParagraph #() >> PRReference #(''reference'' >> ''parameters'') >> PRFigure #() >> PRSlide #(''title'' ''label'') >> PRText #(''text'')' >> >> And show all the emitHTML: messages. >> >> >> And go for a third example, e.g. from Morphic or Bloc >> >> >> position: >> extent: >> color: >> owner: >> submorphs: >> drawOn: aCanvas >> >> >> Meaning of last sentence is not clear. >> >> <citation> >> Remember that when we execute a method (and also write it), one key >> information we get is that the receiver from this class or one of its >> subclasses as we will later. >> <citation> >> >> >> Regards >> >> Hannes >> >> On 9/11/17, Ricardo Pacheco <ricardo.pacheco.roldan(a)gmail.com> wrote: >>> Looks Great, congratulations!! I just read it and has a couple of >>> mistakes >>> in the first figures. The return value of the false (2.3, 2.4). >>> >>> Regards >>> Ricardo >>> >>> El sept. 11, 2017 12:12 AM, "Stephane Ducasse" <stepharo.self(a)gmail.com> >>> escribiÃ³: >>> >>> Hi >>> >>> after this crazy esug I took a long bus and I wrote one missing >>> chapter for the forhtcoming bus. >>> I plan to have a first full version for 1 of October :) >>> >>> I reorganised and massively clean the book contents. >>> >>> Comments are welcome in any form. >>> >>> Stef >>> >>> https://github.com/SquareBracketAssociates/LearningOOPWithPharo >>> >> > >

Sept. 16, 2017

Re: [Pharo-users] UFFI problem / doubt

by Stephane Ducasse

Hi alvaro Thanks for the question. If you have any suggestion for the booklet on UFFI let us know. I will let esteban anwser because I do not know. BTW did you check the chipmunk existing bindings? Stef On Fri, Sep 15, 2017 at 3:42 PM, alvaro piorno <alvaropiorno100(a)gmail.com> wrote: > Hi everybody, iÂ´m using UnifiedFFI with Chipmunk2D library . > I want to get a pointer to a C Structure (cpBody) and set a position to it. > I have a subClass of FFIOpaqueObject to handle pointer. > > This is the "new " ffiCall : > self ffiCall: #(cpBody* cpBodyNew(cpFloat m, cpFloat i)) > > And this is a "seter" ffiCall: > > self ffiCall: #( void cpBodySetPosition( self, cpVect vector ) ). > > I`m not getting any "error" but the position is not updating. > I tried the same using Chipmunk directly and it works, so there is a problem > with what i have in Pharo. > Any suggestion? > Thanks in advance. > > Alvaro Piorno

Sept. 16, 2017

Re: [Pharo-users] PlotMorph on Pharo 6.1

by Stephane Ducasse

I'm on 10.12.6. too I downloaded Pharo 32 using the link. And I loaded from Catalog and I cannot get the problem. May be there is a problem with a setting in the compiler. I will talk to the guys monday. Stef On Fri, Sep 15, 2017 at 2:51 PM, Mark Bestley <st(a)bestley.co.uk> wrote: > Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> --001a113fc0fc9da22e05592a9f54 >> Content-Type: text/plain; charset="UTF-8" >> >> Hi mark >> >> live is chaotic here with two or three meetings in parallel, visitors, >> and a lecture to finish >> Now I tested. I took a Pharo 6.1 32 bits and loaded PlotMorph from the catalog >> It load Stefaneggermont.8 >> >> Can you tell us how to reproduce your problem? >> > > I get this on both 32 and 64 bit Pharo on OSX 10.12.6 > > Loaded a new Pharo from https://pharo.org/web/download and removed > previous Preferences > > Then from Calalog Browser > Install Stable Version > > Then get > >> > >> > Fetched -> ConfigurationOfPlotMorph-StephanEggermont.5 --- >> > http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main/ --- >> > http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main/ >> > Loaded -> ConfigurationOfPlotMorph-StephanEggermont.5 --- >> > http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main/ --- >> > http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo60/main/ >> > Loading 1.1 of ConfigurationOfPlotMorph... >> > Fetched -> PlotMorph-StephanEggermont.8 --- >> > http://smalltalkhub.com/mc/PharoExtras/PlotMorph/main/ --- >> > http://smalltalkhub.com/mc/PharoExtras/PlotMorph/main/ >> > OCStoreIntoReadOnlyVariableError: Cannot store into >> > PlotMorphGrid >> > drawGridOn: aCanvas >> > | gridColor lighter darker baseColor bounds | >> > baseColor := plot baseColor alpha: 1. >> > lighter := baseColor twiceLighter. >> > darker := baseColor twiceDarker. >> > gridColor := (lighter diff: baseColor) > (darker diff: baseColor) >> > ifTrue: [ lighter ] >> > ifFalse: [ darker ]. >> > bounds := plot drawBounds. >> > (bounds left to: bounds right by: (self bestStep: bounds width)) >> > do: [ :x | >> > x := x rounded. >> > aCanvas line: x @ bounds top to: x @ bounds bottom color: >> > gridColor ]. >> > (bounds top to: bounds bottom by: (self bestStep: bounds height)) >> > do: [ :y | >> > y := y rounded. >> > aCanvas line: bounds left @ y to: bounds right @ y color: >> > gridColor ] >> > OCStoreIntoReadOnlyVariableError: Cannot store into >> > PlotMorphGrid >> > drawGridOn: aCanvas >> > | gridColor lighter darker baseColor bounds | >> > baseColor := plot baseColor alpha: 1. >> > lighter := baseColor twiceLighter. >> > darker := baseColor twiceDarker. >> > gridColor := (lighter diff: baseColor) > (darker diff: baseColor) >> > ifTrue: [ lighter ] >> > ifFalse: [ darker ]. >> > bounds := plot drawBounds. >> > (bounds left to: bounds right by: (self bestStep: bounds width)) >> > do: [ :x | >> > x := x rounded. >> > aCanvas line: x @ bounds top to: x @ bounds bottom color: >> > gridColor ]. >> > (bounds top to: bounds bottom by: (self bestStep: bounds height)) >> > do: [ :y | >> > y := y rounded. >> > aCanvas line: bounds left @ y to: bounds right @ y color: >> > gridColor ] >> > OCStoreIntoReadOnlyVariableError: Cannot store into >> > AxesMorph >> > drawGridOn: aCanvas >> > | gridColor right bottom width height lighter darker baseColor | >> > baseColor := self baseColor. >> > lighter := baseColor twiceLighter. >> > darker := baseColor twiceDarker. >> > gridColor := (lighter diff: baseColor) > (darker diff: baseColor) >> > ifTrue: [ lighter ] >> > ifFalse: [ darker ]. >> > right := self bounds width - margin. >> > width := self bounds width - (margin * 2). >> > bottom := self bounds height - margin. >> > height := self bounds height - (margin * 2). >> > (margin to: right by: width / 10) >> > do: [ :x | >> > x := x rounded. >> > aCanvas line: x @ margin to: x @ bottom color: gridColor ]. >> > (margin to: bottom by: height / 10) >> > do: [ :y | >> > y := y rounded. >> > aCanvas line: margin @ y to: right @ y color: gridColor ] >> > OCStoreIntoReadOnlyVariableError: Cannot store into >> > AxesMorph >> > drawGridOn: aCanvas >> > | gridColor right bottom width height lighter darker baseColor | >> > baseColor := self baseColor. >> > lighter := baseColor twiceLighter. >> > darker := baseColor twiceDarker. >> > gridColor := (lighter diff: baseColor) > (darker diff: baseColor) >> > ifTrue: [ lighter ] >> > ifFalse: [ darker ]. >> > right := self bounds width - margin. >> > width := self bounds width - (margin * 2). >> > bottom := self bounds height - margin. >> > height := self bounds height - (margin * 2). >> > (margin to: right by: width / 10) >> > do: [ :x | >> > x := x rounded. >> > aCanvas line: x @ margin to: x @ bottom color: gridColor ]. >> > (margin to: bottom by: height / 10) >> > do: [ :y | >> > y := y rounded. >> > aCanvas line: margin @ y to: right @ y color: gridColor ] >> > Loaded -> PlotMorph-StephanEggermont.8 --- >> > http://smalltalkhub.com/mc/PharoExtras/PlotMorph/main/ --- cache >> > ...finished 1.1 > > > -- > Mark > >

Sept. 16, 2017

Re: [Pharo-users] Pharo 7 license question

by Stephane Ducasse

I do not think that the bootstrap changed anything. :) We will stay away from GPL. May be you can talk to the people of the libraries you want to use and see if they are interested in a dual license. Stef On Fri, Sep 15, 2017 at 10:49 PM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > Hello, > > Pharo 7 to my understanding fundamentally changes Pharo. It is my > understanding that Pharo 7 starts with a core Pharo kernel and like many > languages out there, imports or adds code from a variety of external sources > to the image being built. > > With that understanding, I am curious if that would allow for inclusion of a > specific library/module to be licensed as GPL? And it not affect the other > code in the composed image? > > I am a big believer in the MIT/BSD license and not a big fan of the GPL. > However, there is software out there that I have avoided looking at the > source code or attempting to port it to Pharo because it is GPL. I would > sincerely love if I could now port such a library and license it under the > GPL as required, and it not affect any other code outside of that specific > library. > > I am not a lawyer. Nor do I know any lawyers. Is is possible for someone to > get a reasonably definitive answer on this question? > > I am sure I am not the only one who has had this desire. I am also sure that > I am not the only one who will have this question in the future. So it would > be nice to have a proper legal response that could possibly be explicitly > stated somewhere on the website or on an FAQ or something. > > Regardless of the answer, yes or no. It does need to be a settled issue for > Pharo. That way someone could know if GPL/LGPL or whatever software could be > in the catalog. > > Just wanted to put that out there to the community. I look forward to the > answer, should one be or become available. > > Thanks. > > > Jimmie > > >

Sept. 16, 2017

Re: [Pharo-users] Writing XML

by monty

> Sent: Friday, September 15, 2017 at 4:30 PM > From: "Jimmie Houchin" <jlhouchin(a)gmail.com> > To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Writing XML > > I didn't pay attention to this previously. But I just noticed that using > #printToFileNamed: preserved the DOM tree's original line ending where > as previously I had to insure the the XMLWriter #lineEnding was changed > from defaultLineEnding to canonicalLineEnding. The original document > used LF and not CR. To clarify, #printToFileNamed: and company use CRLF on Windows and LF elsewhere. XMLWriter uses Pharo's LE by default (CR), but it will use the preferred LE of your platform (LF or CRLF) with #enablePlatformSpecificLineBreak, LF when canonical XML (https://www.w3.org/TR/xml-c14n) is enabled, or whatever LE you want with #lineBreak:. You can use #printToFileNamed:beforeWritingDo: with a block that sends #lineBreak: to the writer argument to get a custom LE when printing a DOM tree to a file. > Overall this was a nice win. > It cleaned up my method to save the file and reduced 7 lines to 2. > Nice. :) > > Thanks. > > Jimmie > > > > On 09/15/2017 09:29 AM, monty wrote: > > If you want to write a DOM tree to a file, send #printToFileNamed: (or a related message like #canonicallyPrintToFileNamed: or #printToFileNamed:beforeWritingDo:) to the root. See the XMLNode "printing" category for more. This will automatically encode the file with the encoding the XMLDocument>>#encoding attribute specifies (if recognized), and it's portable across Pharo, Squeak, and GemStone. Use #parseFileNamed:/#onFileNamed: to get portable automatic file decoding when parsing. > > > >> Sent: Wednesday, September 13, 2017 at 1:02 PM > >> From: "Jimmie Houchin" <jlhouchin(a)gmail.com> > >> To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > >> Subject: [Pharo-users] Writing XML > >> > >> Hello, > >> > >> I am attempting to read and write an XML document. > >> > >> Currently I have parsed the document successfully. I have basic > >> navigation and have learned how to modify the XMLDocument. > >> > >> Now I want to write the modified document back to the file system. > >> What I have tried so far is: > >> > >> writer := XMLWriter new. > >> xmldoc document writeXMLOn: writer. > >> writer stream. > >> f := File openForWriteFileNamed: '/home/jimmie/xmldoc.xml'. > >> f nextPutAll: (writer write contents). > >> f flush. > >> f close. > >> > >> It does write an xml document to the file system. However, it has > >> exploded in size. The original is 28mb and is in UTF-8. The newly > >> written file is 112mb and is UTF-32. > >> > >> I do not know why the change in encoding or how to correct or manually > >> set the encoding. > >> > >> Any help in understanding how to correctly write an XML document that I > >> have read and minimally modified would be greatly appreciated. > >> > >> Thanks. > >> > >> Jimmie > >> > >> > > >

Sept. 16, 2017