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

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

by Georg Hagn

Hello Stephane, Definition from: https://mariadb.com/kb/en/mariadb-connectorc-data-structures : "The MYSQL structure represents one database connection and is used by most of MariaDB Connector/C's API functions. The MYSQL structure needs to be allocated and initialized by the mysql_init() API function. It will be released by the mysql_close() function. The MYSQL structure should be considered as opaque." I try with MariaDB, because there is a valid mysql binding. I can test my UFFi Connector agains MySQL. BTW, I use Pharo 8.0 Georg Hagn Am So., 21. Juni 2020 um 16:12 Uhr schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > Hello Georg > > This is a great news. since we need more binding. > I do not really know the answer but Iâm sure the guys will help you. > Now just a question: what is the definition of MYSQL > that you mentioned in > âMYSQL * mysql_init(NULL)â > > > S. > > On 21 Jun 2020, at 11:27, Georg Hagn <georg.hagn(a)gmail.com> wrote: > > For an exercise with uFFi i am try an C-Connector for MariaDB like > Garage or UBDC > As in "Unified FFI Februar 12 2020" I made Helper-classes: > > FFILibrary subclass: #MariaDBLibC > > FFIOpaqueObject subclass: #MariaDBHandle > MariaDBHandle >> unixModuleName [ > ^ '/usr/lib/x86_64-linux-gnu/libmariadb.so' > ] > > and a class > > Object subclass: #MariaDBDriver > instanceVariableNames: 'connectionHandle' > > "Accessors" > MariaDBDriver >> connectionHandle [ ^ connectionHandle ] > MariaDBDriver >> connectionHandle: aHandle [ connectionHandle := aHandle ] > MariaDBDriver class >> ffiLibrary [ ^ MariaDBLibC ] > > "API Methods" > MariaDBDriver >> clientInfo [ ^ self class clientInfo ] > > MariaDBDriver class >> clientInfo [ > ^ self ffiCall: #(String mysql_get_client_info(void)) > ] > > For a first simple Test I choosed the c-api-funtion: > âconst char * mysql_get_client_info(void )â > > In Playground I executed: > driver := MariaDBDriver fromConnectionString: > 'mariaDB://localhost:5432/sodbxtest?&user=sodbxtest&password=sodbxtest'. > > driver clientInfo inspect. > And I get the expected result: String â10.2.9â > > But the second test with c-api-funtcion fails > âMYSQL * mysql_init(NULL)â > > MariaDBDriver >> init [ > | aNullHandle | > aNullHandle := ExternalAddress null. > self connectionHandle: (self class init: aNullHandle). > ] > > MariaDBDriver class >> init: aNullHandle [ > ^ self ffiCall: #(MariaDBHandle * mysql_init(ExternalAddress aNullHandle)). > ] > > In Playground I again executed: > driver := MariaDBDriver fromConnectionString: > 'mariaDB://localhost:5432/sodbxtest?&user=sodbxtest&password=sodbxtest'. > > driver init inspect. > " A call to an external function failed" > > Any ideas what is wrong?? > > Thanks > Georg > > > -------------------------------------------- > 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 21, 2020

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

by StÃ©phane Ducasse

Hello Georg This is a great news. since we need more binding. I do not really know the answer but Iâm sure the guys will help you. Now just a question: what is the definition of MYSQL that you mentioned in âMYSQL * mysql_init(NULL)â S. > On 21 Jun 2020, at 11:27, Georg Hagn <georg.hagn(a)gmail.com> wrote: > > For an exercise with uFFi i am try an C-Connector for MariaDB like > Garage or UBDC > As in "Unified FFI Februar 12 2020" I made Helper-classes: > > FFILibrary subclass: #MariaDBLibC > > FFIOpaqueObject subclass: #MariaDBHandle > MariaDBHandle >> unixModuleName [ > ^ '/usr/lib/x86_64-linux-gnu/libmariadb.so' > ] > > and a class > > Object subclass: #MariaDBDriver > instanceVariableNames: 'connectionHandle' > > "Accessors" > MariaDBDriver >> connectionHandle [ ^ connectionHandle ] > MariaDBDriver >> connectionHandle: aHandle [ connectionHandle := aHandle ] > MariaDBDriver class >> ffiLibrary [ ^ MariaDBLibC ] > > "API Methods" > MariaDBDriver >> clientInfo [ ^ self class clientInfo ] > > MariaDBDriver class >> clientInfo [ > ^ self ffiCall: #(String mysql_get_client_info(void)) > ] > > For a first simple Test I choosed the c-api-funtion: > âconst char * mysql_get_client_info(void )â > > In Playground I executed: > driver := MariaDBDriver fromConnectionString: > 'mariaDB://localhost:5432/sodbxtest?&user=sodbxtest&password=sodbxtest'. > > driver clientInfo inspect. > And I get the expected result: String â10.2.9â > > But the second test with c-api-funtcion fails > âMYSQL * mysql_init(NULL)â > > MariaDBDriver >> init [ > | aNullHandle | > aNullHandle := ExternalAddress null. > self connectionHandle: (self class init: aNullHandle). > ] > > MariaDBDriver class >> init: aNullHandle [ > ^ self ffiCall: #(MariaDBHandle * mysql_init(ExternalAddress aNullHandle)). > ] > > In Playground I again executed: > driver := MariaDBDriver fromConnectionString: > 'mariaDB://localhost:5432/sodbxtest?&user=sodbxtest&password=sodbxtest'. > > driver init inspect. > " A call to an external function failed" > > Any ideas what is wrong?? > > Thanks > Georg > -------------------------------------------- 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 21, 2020

Re: [Pharo-users] [ANN] What are reasons NOT to use Smalltalk?

by Vitor Medina Cruz

+1 On Fri, Jun 19, 2020 at 3:09 PM Todd Blanchard via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Same. My biggest hesitation is lack of cloud deployment support. At > least for web apps. > > For desktop apps, I have been holding off building any UI because of the > brik blok spec spec2 churn. > > On Jun 19, 2020, at 10:02 AM, Richard Sargent < > richard.sargent(a)gemtalksystems.com> wrote: > > It wouldn't let me vote without choosing an answer, none of which were my > answer. > > On Fri, Jun 19, 2020 at 9:32 AM Richard Kenneth Eng < > horrido.hobbies(a)gmail.com> wrote: > >> >> https://smalltalk.tech.blog/2020/06/19/what-are-reasons-not-to-use-smalltal… >> >> >> Thanks for participating in the poll. >> > >

June 21, 2020

UFFI Problem: A call to an external function failed (FFIOpaqueObject)

by Georg Hagn

For an exercise with uFFi i am try an C-Connector for MariaDB like Garage or UBDC As in "Unified FFI Februar 12 2020" I made Helper-classes: FFILibrary subclass: #MariaDBLibC FFIOpaqueObject subclass: #MariaDBHandle MariaDBHandle >> unixModuleName [ ^ '/usr/lib/x86_64-linux-gnu/libmariadb.so' ] and a class Object subclass: #MariaDBDriver instanceVariableNames: 'connectionHandle' "Accessors" MariaDBDriver >> connectionHandle [ ^ connectionHandle ] MariaDBDriver >> connectionHandle: aHandle [ connectionHandle := aHandle ] MariaDBDriver class >> ffiLibrary [ ^ MariaDBLibC ] "API Methods" MariaDBDriver >> clientInfo [ ^ self class clientInfo ] MariaDBDriver class >> clientInfo [ ^ self ffiCall: #(String mysql_get_client_info(void)) ] For a first simple Test I choosed the c-api-funtion: âconst char * mysql_get_client_info(void )â In Playground I executed: driver := MariaDBDriver fromConnectionString: 'mariaDB://localhost:5432/sodbxtest?&user=sodbxtest&password=sodbxtest'. driver clientInfo inspect. And I get the expected result: String â10.2.9â But the second test with c-api-funtcion fails âMYSQL * mysql_init(NULL)â MariaDBDriver >> init [ | aNullHandle | aNullHandle := ExternalAddress null. self connectionHandle: (self class init: aNullHandle). ] MariaDBDriver class >> init: aNullHandle [ ^ self ffiCall: #(MariaDBHandle * mysql_init(ExternalAddress aNullHandle)). ] In Playground I again executed: driver := MariaDBDriver fromConnectionString: 'mariaDB://localhost:5432/sodbxtest?&user=sodbxtest&password=sodbxtest'. driver init inspect. " A call to an external function failed" Any ideas what is wrong?? Thanks Georg

June 21, 2020

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

by StÃ©phane Ducasse

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 <mailto:raoknz@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 <mailto:emaringolo@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 <mailto:whaley.russ@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 <mailto:whaley.russ@gmail.com> > > -- > Russ Whaley > whaley.russ(a)gmail.com <mailto:whaley.russ@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, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

June 20, 2020

Re: [Pharo-users] [ANN] What are reasons NOT to use Smalltalk?

by StÃ©phane Ducasse

A little point in the discussion. If you do not contribute then there is less chance that the situation will improve. Look at Sven, he is running a business for real. Still he develops and documents and shares with all of you Zinc Neo suite Chapter and script on deployment. So yes we do not have one click solutions but we are not millions of people. Still some people do successfully deploy Pharo app and automate it. Now about JS framework. We stopped maintaining some JS app just because everything was moving under our feets even the package manager. In a project to migrate from GWT to Angular the angular versions changed in the curse of the project. So at the end of the day when you think about what you have done, you can also think about what you have done for improving the ecosystem. Because if you only count on other work then complain. S.

June 20, 2020

Re: [Pharo-users] [ANN] What are reasons NOT to use Smalltalk?

by horrido

I decided to add a new option: "None of the above (add a comment for a new answer)." Hopefully, this fixes the issue. Richard Sargent wrote > On Fri, Jun 19, 2020 at 11:39 AM horrido < > horrido.hobbies@ > > wrote: > >> I'm not sure I understand. Are you saying you tried to submit "Vote" >> without >> checking off any of the boxes? >> > > Yes, that is what I am saying. None of those are reasons to NOT use > Smalltalk, in my opinion. > > >> You can always add comment to the post. >> >> >> >> Richard Sargent wrote >> > It wouldn't let me vote without choosing an answer, none of which were >> my >> > answer. >> > >> > On Fri, Jun 19, 2020 at 9:32 AM Richard Kenneth Eng < >> >> > horrido.hobbies@ >> >> >> wrote: >> > >> >> >> >> >> https://smalltalk.tech.blog/2020/06/19/what-are-reasons-not-to-use-smalltal… >> >> >> >> >> >> Thanks for participating in the poll. >> >> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 20, 2020

Re: [Pharo-users] [ANN] What are reasons NOT to use Smalltalk?

by horrido

That's a limitation of the WordPress poll. It doesn't really allow you to add additional answers. However, what you can do is go to "View Results", click on "Comments" at the bottom of the poll widget, and add a comment, which can include a new answer. It's not ideal, but that's all Wordpress allows, I'm afraid. Richard Sargent wrote > On Fri, Jun 19, 2020 at 11:39 AM horrido < > horrido.hobbies@ > > wrote: > >> I'm not sure I understand. Are you saying you tried to submit "Vote" >> without >> checking off any of the boxes? >> > > Yes, that is what I am saying. None of those are reasons to NOT use > Smalltalk, in my opinion. > > >> You can always add comment to the post. >> >> >> >> Richard Sargent wrote >> > It wouldn't let me vote without choosing an answer, none of which were >> my >> > answer. >> > >> > On Fri, Jun 19, 2020 at 9:32 AM Richard Kenneth Eng < >> >> > horrido.hobbies@ >> >> >> wrote: >> > >> >> >> >> >> https://smalltalk.tech.blog/2020/06/19/what-are-reasons-not-to-use-smalltal… >> >> >> >> >> >> Thanks for participating in the poll. >> >> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 20, 2020

Re: [Pharo-users] [ANN] What are reasons NOT to use Smalltalk?

by Russ Whaley

Agreed. My biggest issues are non-multiplatform - development and deployment (specifically iOS/mobile support -in a single downloadable IDE). And while I love Pharo, and all the brilliant people who work very hard to make it the best Smalltalk environment available... I shouldnât have to struggle for months trying to build a usable GUI front end. An LTS model may go a long way in this area, or it could just keep all the cool stuff from ever seeing the light of day. :) All that said, I have preferred Smalltalk since my earliest introductions in the early Digitalk days. I went on to Java and C# - and I can easily build UIâs and deploy multi-platform in these environments... - but I really, REALLY like and prefer Smalltalk. Cheers everyone! On Fri, Jun 19, 2020 at 12:32 PM Richard Kenneth Eng < horrido.hobbies(a)gmail.com> wrote: > > https://smalltalk.tech.blog/2020/06/19/what-are-reasons-not-to-use-smalltal… > > > Thanks for participating in the poll. > -- Russ Whaley whaley.russ(a)gmail.com

June 19, 2020

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

by Russ Whaley

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

June 19, 2020