September 2017 - Pharo-users

Re: [Pharo-users] UFFI problem / doubt

by Ben Coman

On Mon, Sep 18, 2017 at 12:01 AM, alvaro piorno <alvaropiorno100(a)gmail.com> wrote: > Pierce: I already see the repo, i kwnow now the difference and is not the > problem i have now. I made the suggestion for book draft i found, because > theres is no example on it. Thanks for answer. > > Stephan : Yes, as Esteban said iÂ´m using that, IÂ´m extending (or trying) > EstebanÂ´s project. And iÂ´m having the problem that esteban metioned. Thanks > for answer. > > Ben: I have in C the same example as in Pharo using the physics of Chipmunk, > and in C is working fine, there is a problem in the call to the function > from Pharo in 64 bits. Thanks for answer. Replicating the same example in C was not my point. You'd said you'd already done that ;) I meant compile your own shared C library containing... cpBody* myBodyNew(cpFloat m, cpFloat i)) { printf( "....\n", m, i ); cpBodyNew(cpFloat m, cpFloat i); } and from Smalltalk use... self ffiCall: #(cpBody* myBodyNew(cpFloat m, cpFloat i)) also changing your existing C example to also use myBodyNew() to confirm it works as expected. cheers -ben > > > 2017-09-17 12:11 GMT-03:00 Ben Coman <btc(a)openinworld.com>: >> >> >> On Fri, Sep 15, 2017 at 9: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. >> >> >> A general approach might be to write your own C wrapper around Chipmunk >> library functions which >> just does a debug printout of parameters before calling the wrapped >> function. >> Use these for both from Pharo and your "direct" trial, and see how they >> compare. >> >> cheers -ben >> >

Sept. 17, 2017

Re: [Pharo-users] Standalone HTML Model

by Stephane Ducasse

Ok I will try to digest it :) I do not remember how this is done in Pillar but this is a visitor and it could call a streaming generator. Stef On Sun, Sep 17, 2017 at 2:10 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 17.09.2017 um 13:34 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Norbert can you explain the difference between "a HTML model that can >> be used for streaming, too, instead just the streaming." >> because indeed in Pillar we have another HTML exporter and I would >> like to reuse :) > > The difference is having a streaming API like seaside that uses brushes to write a HTML tag with its attributes and uses blocks to nest tags. This way at the end of the code you don't have a document model but a serialized form of the DOM that depends on the canvas you use. > The standalone HTML model would be a DOM on which you can work afterwards. You can navigate, decorate etc. before serializing this the a html string. For the PharoJS this would ease the development in the pharo image. For pillar it would be a theoretical improvement to convert a pillar DOM to a HTML DOM and this to a HTML string representation. But as long as the benefits aren't clear the intermediate step for pillar likes a bit too much. > But I have the strong feeling it would be good if there would be more directions you can go. We have a good XML parser that produces a XML DOM. We have pillar with its own DOM that can be converted to HTML. I don't know what SOUP is producing. And we have web frameworks where people have different ways producing for the web. I see potential in supporting multiple ways of reading and writing HTML and making this experience much more powerful. > > Norbert >>> On Sun, Sep 17, 2017 at 1:29 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> >>>>> Am 17.09.2017 um 12:12 schrieb Pierce Ng <pierce(a)samadhiweb.com>: >>>>> >>>>> On Mon, Sep 11, 2017 at 06:25:55PM +0200, Stephane Ducasse wrote: >>>>> Hi Pierce Ng >>>>> How different is the API from Seaside? >>>>> Because I would like to use it. >>>>> I like to think modularly :) >>>> >>>> Hi Stef, >>>> >>>> I modeled it after Seaside's API. However, it was really just a start and needs >>>> much more work. I created this when investigating writing web apps in Cuis, >>>> hence the perceived need for a standalone library. Eventually I ran out of time >>>> and decided to stick to full Seaside loaded into Pharo. >>>> >>> So you've built something like seaside canvas? I like to emphasize that seaside is not really a standalone HTML model but (as the name says) a canvas which streams markup. >>> What we should explore is the possibility of having a HTML model that can be used for streaming, too, instead just the streaming. There could be a lot of synergies here because web frameworks, pillar, PharoJS are all working close to something like that. >>> >>> my 2 cents, >>> >>> Norbert >

Sept. 17, 2017

Re: [Pharo-users] Pharo 7 license question

by Ben Coman

On Sun, Sep 17, 2017 at 7:00 PM, stephan <stephan(a)stack.nl> wrote: > > On 17-09-17 06:59, Jimmie Houchin wrote: >> >> And the GPL not be viral in my app provided I only use the GPL library and am not modifying it in my app. >> >> Do I understand this wrong? > > > Yes. With GPL everything is now GPL. With LGPL, as long as you only link to it, > the viral aspect is limited to the library. In Pharo, that means you can use UFFI > to connect to LGPL libraries, and you can probably create plugins. Loading > smalltalk libraries that are LGPL is not exactly the same as linking, there is > no clear boundary between compile-time and run-time, as everything is in the image. > That makes the LGPL difficult to interpret in the smalltalk case, and potentially viral. +1. On Sun, Sep 17, 2017 at 6:09 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Regarding porting GPL software, I guess you mean rewriting with Smalltalk, > you should be free to license it as you want, for example as MIT. > AFAIK there is no evil restriction as "seen the code" under the GPL. It is not as clean as that. Many consider "seen the code" to implicate "derived code". Whether a court of law agrees with this or not is not what you should consider. The best advice I received from a lawyer is that winning in court (sometimes after years of effort) is still a loss, so you should position yourself so that no one even thinks they can take you court. > For library, alternative is LGPL and I read this interesting note: > One should note that subclassing a Java (or other OO) class licensed under the LGPL is regarded as a use of an interface of a library comparable to a function call of a library. It is not regarded as a modification of the original class. Therefore the subclass does not fall under the requirements of the LGPL. The definitive reference of Java + LGPL is https://www.gnu.org/licenses/lgpl-java.en.html which says: "The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's âimportâ functionality to access classes from these libraries ... The LGPL permits this distribution ... Applications need only follow the requirements in section 6 of the LGPL" but a Smalltalk Image runs foul of section 6 requiring... "A suitable [shared library] mechanism ... that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable" where an Image is considered to be the "executable". So incorporating LGPL Smalltalk code into an Image causes all code in the Image to be infected with the LGPL. > So using a LGPL library, even extending it, does not force the user to be in the GPL family license. Using LGPL C libraries is fine and doesn't infect your Smalltalk code. Using LGPL Smalltalk libraries does infect all Smalltalk code in your Image. The concern is contributing a bug fixed in Pharo code from an infected image technically infects the whole of Pharo - although you are free to update a clean image with the same bug fix and contribute from there - but thats an awkward process. > The only restriction is the receiver should be capable to update > the LGPL package independently of the application using the package. > Anyway, I don't think you should worried about porting GPL/LGPL libraries as long > as your are rewriting it. You can license it under MIT. Then LGPL is also possible. The term "port" clearly implies "derived" so you cannot arbitrarily re-license just by changing implementation languages. Otherwise for example a GPL library could be relicensed by one team porting from C to Python, then a second independent team ports from Python back to C subverting the original copyright. =============== Hmmm... actually refreshing myself with the newer license texts just now I notice GPL 3 has added some interesting definitions the GPL 2 lacks... > The âCorresponding Sourceâ for a work ... does not include the work's System Libraries > > The âSystem Librariesâ of an executable work include anything, other than the work as a whole, that > (a) is included in the normal form of packaging a Major Component, > but which is not part of that Major Component, and > (b) serves only to enable use of the work with that Major Component, or to implement a > Standard Interface for which an implementation is available to the public in source code form. > > A âMajor Componentâ, in this context, means a major essential component > (kernel, window system, and so on) of the specific operating system (if any) > on which the executable work runs, or a compiler used to produce the work, > or an object code interpreter used to run it. > > A âStandard Interfaceâ means an interface that > ... is widely used among developers working in that language. which seems to open the door to a strong argument** that Pharo is such a Major Component protected from even a full GPL3 coded application being loaded and run - i.e. you could fix and contribute Pharo code directly from such an Image - but other non-GPL Smalltalk libraries you mix in may not be similarly protected. But it still seems a grey area with compliance easier to manage using nonCopyLeft licenses. cheers -ben ** You'd probably want the FSF to directly issue a statement on this.

Sept. 17, 2017

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

by Stephane Ducasse

For the Visitor chapter it is in preparation... (first I should finish the lecture schedule and after do another pass on the first book ) it will be an extension of the Expression chapter On Sat, Sep 16, 2017 at 1:53 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > 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. 17, 2017

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

by Stephane Ducasse

once you are done please share it. You see I'm good in deep little details but I often lack other knowledge :) On Sun, Sep 17, 2017 at 9:59 AM, Daniel BLANC <daniel.blanc(a)gmail.com> wrote: > Thanks Stef, this app is just a quick hack but I already can stop the wifi > from my phone and I feel like I have new negociations superpowers... > > Thanks HernÃ¡n ! That's a perfect fit :) > > On Thu, Sep 14, 2017 at 9:24 PM HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> >> http://www.smalltalkhub.com/#!/~TorstenBergmann/Scheduler >> >> Cheers, >> >> HernÃ¡n >> >> 2017-09-13 17:36 GMT-03:00 Daniel BLANC <daniel.blanc(a)gmail.com>: >> > Hi All, >> > >> > I'm a very beginner with smalltalk. I am building a small seaside app >> > for >> > controlling wifi access of my teenagers kids. In this app I need to >> > start or >> > stop the wifi acces at a given time. >> > For the moment I'm doing it with an infinite loop in a process, with >> > this >> > code: >> > >> > WifiController >> startScheduler >> > ^ SchedulerProcess >> > ifNil: [ SchedulerProcess := [ [ true ] >> > whileTrue: [ self schedulerApplyAutoStartStopRules. >> > 56 seconds wait ] ] forkNamed: 'DanWifiManagerScheduler' ] >> > >> > >> > I'm wondering if there is a way to do this without this infinite loop ? >> > May >> > be there is a class in the standard pharo image that can execute a code >> > block at a given time ? >> > >> > Thanks, >> > Daniel >> >

Sept. 17, 2017

Re: [Pharo-users] UFFI problem / doubt

by Stephane Ducasse

Esteban and you remember you promise me to work on the documentation :) On Sun, Sep 17, 2017 at 1:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yes, he is using that. > but he is porting it yo UFFI (it was NB) and to 64bits and to Chipmunk 7.0 (it was 6.1) > > Soâ¦ in one of those places, is failing :( > > Esteban > >> On 17 Sep 2017, at 13:32, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Look at http://smalltalkhub.com/#!/~estebanlm/Storm >> >> A small game engine. >> >> For being able to use this you will need: >> >> NB capable VM. >> Athens. >> Chipmunk library. You can download it at Chipmunk >> >> On Sun, Sep 17, 2017 at 1:31 PM, Stephane Ducasse >> <stepharo.self(a)gmail.com> wrote: >>> Jean-Baptiste Arnaud extended the Chipmunk binding that esteban did a >>> while ago and Damien Pollet did a tutorial >>> at ESUG Annecy to show how to use FFI (nativeboost) to call chipmunk >>> so it should be around. >>> >>> Stef >>> >>> On Sat, Sep 16, 2017 at 2:09 PM, alvaro piorno >>> <alvaropiorno100(a)gmail.com> wrote: >>>> 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. 17, 2017

Color text formatting in Transcript

by Yuriy Babah

Hello! Is there a simple way to apply color formatting to text in Transcript, accessible for amateur? Thank!

Sept. 17, 2017

Re: [Pharo-users] UFFI problem / doubt

by alvaro piorno

Pierce: I already see the repo, i kwnow now the difference and is not the problem i have now. I made the suggestion for book draft i found, because theres is no example on it. Thanks for answer. Stephan : Yes, as Esteban said iÂ´m using that, IÂ´m extending (or trying) EstebanÂ´s project. And iÂ´m having the problem that esteban metioned. Thanks for answer. Ben: I have in C the same example as in Pharo using the physics of CHipmunk, and in C is working fine, there is a problem in the call to the function from Pharo in 64 bits. Thanks for answer. 2017-09-17 12:11 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > On Fri, Sep 15, 2017 at 9: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. >> > > A general approach might be to write your own C wrapper around Chipmunk > library functions which > just does a debug printout of parameters before calling the wrapped > function. > Use these for both from Pharo and your "direct" trial, and see how they > compare. > > cheers -ben > >

Sept. 17, 2017

Re: [Pharo-users] UFFI problem / doubt

by Ben Coman

On Fri, Sep 15, 2017 at 9: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. > A general approach might be to write your own C wrapper around Chipmunk library functions which just does a debug printout of parameters before calling the wrapped function. Use these for both from Pharo and your "direct" trial, and see how they compare. cheers -ben

Sept. 17, 2017

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

by Sean P. DeNigris

Daniel BLANC wrote > I feel like I have new negociations superpowers... The magic of Smalltalk ha ha :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 17, 2017