June 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Want to contribute.... it is easy

by Jeff Gray

Are there any that you would prioritise, or just a top to bottom? And are we assuming American or British English? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 24, 2020

Re: [Pharo-users] [Pharo-dev] [ANN] PharoPro

by Mariano Martinez Peck

A bit late to the party, but I still wanted to congratulate everyone involved and wish you all the best. I said (but didn't do) many times in the past that having a LTS version would be really good. So I hope you can make it. Also, thanks for the FAQ entry comparing with the Consortium, as that was my immediate question hhahaha. Best, On Wed, Jun 17, 2020 at 10:07 PM Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Wed, Jun 17, 2020 at 10:34:09AM +0200, Norbert Hartl wrote: > > we are very proud to announce the availability of PharoPro, a company > > that offers professional support for the pharo platform. Our mission > > is to enable people and companies to secure their business when > > building products with pharo. > > Great stuff! All the best! > > Pierce > > > -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> Blog: https://marianopeck.wordpress.com/

June 23, 2020

Re: [Pharo-users] UFFI Problem: A call to an external function failed (FFIOpaqueObject)

by Sven Van Caekenberghe

Hi Pierce, > On 23 Jun 2020, at 11:51, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > On Mon, Jun 22, 2020 at 08:41:22AM +0200, Sven Van Caekenberghe wrote: >>> On 22 Jun 2020, at 03:47, Pierce Ng <pierce(a)samadhiweb.com> wrote: >>> Finally, there is a non FFI pure Smalltalk implementation of the MySQL >>> wire protocol that has been around a while. >> >>> https://github.com/pharo-rdbms/Pharo-MySQL >> >> Hmm, that is interesting, I somehow missed that. >> A little bit more documentation, like a description in the README file would be great though. > > Agree. Your docu for P3 is the standard to aim for. Thanks, but I still do not consider P3 completely documented, though as far as a README in GitHub goes it is quite good. > Quick bit of history: This driver is the one from Squeaksource that was > then incorporated into DBXTalk and Garage, and finally moved to the GH > repo mentioned above. > > http://www.squeaksource.com/StdbMysqlProtocol.html Ah, OK. Then the origins and original authors should definitively be acknowledged. > Pierce Regards, Sven

June 23, 2020

Re: [Pharo-users] UFFI Problem: A call to an external function failed (FFIOpaqueObject)

by Pierce Ng

On Mon, Jun 22, 2020 at 08:41:22AM +0200, Sven Van Caekenberghe wrote: > > On 22 Jun 2020, at 03:47, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > Finally, there is a non FFI pure Smalltalk implementation of the MySQL > > wire protocol that has been around a while. > > > https://github.com/pharo-rdbms/Pharo-MySQL > > Hmm, that is interesting, I somehow missed that. > A little bit more documentation, like a description in the README file would be great though. Agree. Your docu for P3 is the standard to aim for. Quick bit of history: This driver is the one from Squeaksource that was then incorporated into DBXTalk and Garage, and finally moved to the GH repo mentioned above. http://www.squeaksource.com/StdbMysqlProtocol.html Pierce

June 23, 2020

Want to contribute.... it is easy

by StÃ©phane Ducasse

Hi If you are a native english speaker (or just good in english) have limited amount of time but still want to contribute You can be on the other side and contribute to Pharo. Please consider reading the books and making Pull Requests on the github repositories. You do not have to know Pillar, you do not have to install LaTeX, you do not have to know LaTeX, you do not even have to be good in Pharo, you just have to read and do a PR request. All our books are built automatically on PRs! https://github.com/SquareBracketAssociates/ I would like to publicly thanks Sean de Nigris Ted Brunz Rene Pierre Mages for their large edit pass on the books. S. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

June 22, 2020

Re: [Pharo-users] UFFI Problem: A call to an external function failed (FFIOpaqueObject)

by Sven Van Caekenberghe

> On 22 Jun 2020, at 03:47, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > Finally, there is a non FFI pure Smalltalk implementation of the MySQL > wire protocol that has been around a while. > https://github.com/pharo-rdbms/Pharo-MySQL Hmm, that is interesting, I somehow missed that. A little bit more documentation, like a description in the README file would be great though. Sven

June 22, 2020

Re: [Pharo-users] Cant able to run EXE file using LibC

by Christopher Fuhrman

Hello, Try the following: result := LibC runCommand: ' D:\DEV_FreeCAD\build\bin\test1.exe >output 2> > errors'. > 'errors' asFileReference contents lines. > You can view the file 'errors' for more information On Thu, 18 Jun 2020 at 10:48, shawon58 <shawonhoque58(a)gmail.com> wrote: > Hello > I am trying to run "LibC system: 'D:\DEV_FreeCAD\build\bin\test1.exe' " . > But it dont execute. But if i click the test1.exe than it execute. > > > Thanks for the help > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

June 22, 2020

Re: [Pharo-users] UFFI Problem: A call to an external function failed (FFIOpaqueObject)

by Pierce Ng

On Sun, Jun 21, 2020 at 11:27:22AM +0200, Georg Hagn wrote: > 'mariaDB://localhost:5432/sodbxtest?&user=sodbxtest&password=sodbxtest'. Hi, Firstly, 5432 is PostgreSQL. MySQL/MariaDB default port is 3306. Just a note, as mysql_init() only allocates the C level structure and doesn't connect. > FFILibrary subclass: #MariaDBLibC > > FFIOpaqueObject subclass: #MariaDBHandle > MariaDBHandle >> unixModuleName [ > ^ '/usr/lib/x86_64-linux-gnu/libmariadb.so' > ] With your code, implementing #unixModuleName in MariaDBLibC works for me. I've never done that in FFIOpaqueObject subclasses. In terms of organizing code, suggest you implement the FFI calls in MariaDBLibC itself and do away with MariaDBDriver. Having the FFI calls in MariaDBDriver while using MariaDBLibC only for locating the C libraries is using two classes where one will do. Finally, there is a non FFI pure Smalltalk implementation of the MySQL wire protocol that has been around a while. If you are doing this FFI thing for practice, I recommend that you wrap another C library, so that when you are done, Pharo gets another C library binding. https://github.com/pharo-rdbms/Pharo-MySQL Pierce

June 22, 2020

Re: [Pharo-users] a simple question (I think)

by Richard Sargent

On Sun, Jun 21, 2020, 14:54 Russ Whaley <whaley.russ(a)gmail.com> wrote: > Why? (question, not a challenge :) ) > > - I really only use it in a Logger class I developed that letâs me know at > the time of logging, what method and class Iâm in - ... write to the log... > done. > That's a reasonable use. In general, you don't use it to derive meaning that your program relies on. Stack reporting is a good use. Your logging use is a degenerate case of stack reporting. > On Sat, Jun 20, 2020 at 3:08 AM StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> as a general principle do not use thisContext. >> >> >> S. >> >> >> On 20 Jun 2020, at 01:12, Russ Whaley <whaley.russ(a)gmail.com> wrote: >> >> Thank you both for your insights. Iâve done the newFor: style many times, >> but where it falls short is when I read in a STON object. No worries, I was >> just wondering if there was something cool like âwhat object am I sitting >> on?â... I looked through Context and the client message will be helpful to >> me in other areas. Iâm always eager to learn. Thank you very much for being >> willing to teach. >> >> Thanks! >> Russ >> >> On Wed, Jun 17, 2020 at 9:05 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: >> >>> I have a strong dislike for incompletely initialised objects. >>> So I would do it like this: >>> >>> myInstVar := TheDependentClass newFor: self. >>> >>> (together with any other essential information as parameters). >>> In my Smalltalk system it would look like this: >>> >>> Whatever subclass: #TheDependentClass >>> instanceConstantNames: 'owner' >>> ... >>> class methods for: 'instance creation' >>> newFor: owner >>> ^(self basicNew) pvtOwner: owner; yourself >>> >>> methods for: 'initialising' >>> pvtOwner: anObject >>> super pvtPostNew. >>> owner := anObject. >>> >>> Private access to methods with a 'pvt' prefix is enforced. >>> Instance constants can only be set in private methods. >>> There's an additional wrinkle that makes it a run time >>> error to call TheDependentClass new, so that you cannot get >>> an incompletely initialised object. >>> >>> In any Smalltalk you can follow similar conventions even if >>> they are not enforced. >>> >>> Of course if you don't mind incompletely initialised objects, >>> nothing stops you writing code that allows them. The question >>> is whether you want to be able to trust the 'owner' field or >>> not. >>> >>> On Thu, 18 Jun 2020 at 09:46, Esteban Maringolo <emaringolo(a)gmail.com> >>> wrote: >>> >>>> Objects interact with each other by sending messages, although you can >>>> get the sender by using reflection (thisContext sender), it is not a >>>> common practice to do so. >>>> So if you need another object to know the sender (or any other object) >>>> you simply pass it as a parameter. >>>> >>>> So modifying your example, and making the syntax actually work it would >>>> be: >>>> >>>> self property: ObjectClass new. >>>> self property caller: self. >>>> >>>> and then when you need to deal with that you can simply get a >>>> reference to that object and send it a message to do something: >>>> self property caller doSomething. >>>> >>>> You can also have something like >>>> >>>> self property: (ObjectClass for: self) >>>> >>>> >>>> In that case the #for: message is received by "ObjectClass class", >>>> which you can think of as if it were a Factory or a "static" method >>>> (it is not! it is much more powerful than that). >>>> >>>> ObjectClass class>>#for: callerObject >>>> ^self new >>>> setCaller: callerObject; >>>> yourself >>>> >>>> And that's it, you have an instance of ObjectClass that you >>>> initialized by sending #for: instead of #new (internally it ended up >>>> calling #new, but from the outside it was just a message send). >>>> >>>> And for the most part that's Smalltalk: Objects and messages. >>>> >>>> Regards! >>>> >>>> Esteban A. Maringolo >>>> >>>> On Wed, Jun 17, 2020 at 6:19 PM Russ Whaley <whaley.russ(a)gmail.com> >>>> wrote: >>>> > >>>> > I find myself, over and over, creating a & storing q new object in an >>>> instVar, then storing (my)self on that object - so I can have easy access >>>> to the 'object that created me.' >>>> > >>>> > <what I do now...> >>>> > >>>> > self instVar := NewClass new. >>>> > >>>> > self instVar callingObject: self. >>>> > >>>> > "where these call the same messages" >>>> > >>>> > self myMessage. >>>> > >>>> > self instVar callingObject myMessage. >>>> > >>>> > <is there a way to...> >>>> > >>>> > self instVar := NewClass new. >>>> > >>>> > self instVar objectWhoCreatedMe myMessage. >>>> > >>>> > "I know there is a 'thisContext sender' - but is there a 'who created >>>> me' concept?" >>>> > >>>> > >>>> > Ultimately, there is no real overhead to storing (my)self on a new >>>> object, I guess, but as I'm developing and testing, I tend to have a whole >>>> lot of 'stranded objects' I have to remove manually. >>>> > >>>> > Thoughts? >>>> > >>>> > Thanks! >>>> > -- >>>> > Russ Whaley >>>> > whaley.russ(a)gmail.com >>>> >>>> -- >> Russ Whaley >> whaley.russ(a)gmail.com >> >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Aurore Dalle >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley >> <https://www.google.com/maps/search/40,+avenue+Halley?entry=gmail&source=g> >> , >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >> -- > Russ Whaley > whaley.russ(a)gmail.com >

June 21, 2020

Re: [Pharo-users] a simple question (I think)

by Russ Whaley

Why? (question, not a challenge :) ) - I really only use it in a Logger class I developed that letâs me know at the time of logging, what method and class Iâm in - ... write to the log... done. On Sat, Jun 20, 2020 at 3:08 AM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > as a general principle do not use thisContext. > > > S. > > > On 20 Jun 2020, at 01:12, Russ Whaley <whaley.russ(a)gmail.com> wrote: > > Thank you both for your insights. Iâve done the newFor: style many times, > but where it falls short is when I read in a STON object. No worries, I was > just wondering if there was something cool like âwhat object am I sitting > on?â... I looked through Context and the client message will be helpful to > me in other areas. Iâm always eager to learn. Thank you very much for being > willing to teach. > > Thanks! > Russ > > On Wed, Jun 17, 2020 at 9:05 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: > >> I have a strong dislike for incompletely initialised objects. >> So I would do it like this: >> >> myInstVar := TheDependentClass newFor: self. >> >> (together with any other essential information as parameters). >> In my Smalltalk system it would look like this: >> >> Whatever subclass: #TheDependentClass >> instanceConstantNames: 'owner' >> ... >> class methods for: 'instance creation' >> newFor: owner >> ^(self basicNew) pvtOwner: owner; yourself >> >> methods for: 'initialising' >> pvtOwner: anObject >> super pvtPostNew. >> owner := anObject. >> >> Private access to methods with a 'pvt' prefix is enforced. >> Instance constants can only be set in private methods. >> There's an additional wrinkle that makes it a run time >> error to call TheDependentClass new, so that you cannot get >> an incompletely initialised object. >> >> In any Smalltalk you can follow similar conventions even if >> they are not enforced. >> >> Of course if you don't mind incompletely initialised objects, >> nothing stops you writing code that allows them. The question >> is whether you want to be able to trust the 'owner' field or >> not. >> >> On Thu, 18 Jun 2020 at 09:46, Esteban Maringolo <emaringolo(a)gmail.com> >> wrote: >> >>> Objects interact with each other by sending messages, although you can >>> get the sender by using reflection (thisContext sender), it is not a >>> common practice to do so. >>> So if you need another object to know the sender (or any other object) >>> you simply pass it as a parameter. >>> >>> So modifying your example, and making the syntax actually work it would >>> be: >>> >>> self property: ObjectClass new. >>> self property caller: self. >>> >>> and then when you need to deal with that you can simply get a >>> reference to that object and send it a message to do something: >>> self property caller doSomething. >>> >>> You can also have something like >>> >>> self property: (ObjectClass for: self) >>> >>> >>> In that case the #for: message is received by "ObjectClass class", >>> which you can think of as if it were a Factory or a "static" method >>> (it is not! it is much more powerful than that). >>> >>> ObjectClass class>>#for: callerObject >>> ^self new >>> setCaller: callerObject; >>> yourself >>> >>> And that's it, you have an instance of ObjectClass that you >>> initialized by sending #for: instead of #new (internally it ended up >>> calling #new, but from the outside it was just a message send). >>> >>> And for the most part that's Smalltalk: Objects and messages. >>> >>> Regards! >>> >>> Esteban A. Maringolo >>> >>> On Wed, Jun 17, 2020 at 6:19 PM Russ Whaley <whaley.russ(a)gmail.com> >>> wrote: >>> > >>> > I find myself, over and over, creating a & storing q new object in an >>> instVar, then storing (my)self on that object - so I can have easy access >>> to the 'object that created me.' >>> > >>> > <what I do now...> >>> > >>> > self instVar := NewClass new. >>> > >>> > self instVar callingObject: self. >>> > >>> > "where these call the same messages" >>> > >>> > self myMessage. >>> > >>> > self instVar callingObject myMessage. >>> > >>> > <is there a way to...> >>> > >>> > self instVar := NewClass new. >>> > >>> > self instVar objectWhoCreatedMe myMessage. >>> > >>> > "I know there is a 'thisContext sender' - but is there a 'who created >>> me' concept?" >>> > >>> > >>> > Ultimately, there is no real overhead to storing (my)self on a new >>> object, I guess, but as I'm developing and testing, I tend to have a whole >>> lot of 'stranded objects' I have to remove manually. >>> > >>> > Thoughts? >>> > >>> > Thanks! >>> > -- >>> > Russ Whaley >>> > whaley.russ(a)gmail.com >>> >>> -- > Russ Whaley > whaley.russ(a)gmail.com > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley > <https://www.google.com/maps/search/40,+avenue+Halley?entry=gmail&source=g> > , > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > -- Russ Whaley whaley.russ(a)gmail.com

June 21, 2020