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

Cant able to run EXE file using LibC

by shawon58

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

June 18, 2020

Re: [Pharo-users] Want to run C code in Pharo using UFFI

by Rob van Lopik

You may want to have a look at: https://fuhrmanator.github.io/2019/03/16/LibC-Pharo-experiments.html hth rob van lopik > > ******************************************* >

June 18, 2020

Re: [Pharo-users] Want to run C code in Pharo using UFFI

by TomaÅ¾ Turk

OK - maybe I misunderstood your original question - the purpose of UFFI is to call functions in DLLs outside Pharo, so yes, if you would like to call that kind of function, you have to build a DLL. The usage of UFFI is well described in its booklet: https://books.pharo.org/booklet-uffi/. Best wishes Tomaz

June 18, 2020

Re: [Pharo-users] Want to run C code in Pharo using UFFI

by shawon58

hello that means i need to create a ddl file and copy that file to pharo folder than try to run the command directly using UFFI like system("D:/DEV_FreeCAD/build/bin/box.step") is it what u are trying to say @TOMAZ Thanks by Shawon -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 18, 2020

Re: [Pharo-users] Want to run C code in Pharo using UFFI

by TomaÅ¾ Turk

Hi, as far as I know UFFI can call DLLs, that means that your code should be compiled and linked into a DLL. So maybe the line to pursue is to look for a C interpreter (like in https://stackoverflow.com/questions/584714/is-there-an-interpreter-for-c) and call it via UFFI. Best wishes, Tomaz

June 18, 2020

Want to run C code in Pharo using UFFI

by shawon58

Hello There i am new to Pharo, so as i learn UFFI can handle c code, but i want to know that, how to run below attached code using UFFI. #include<stdlib.h> #include<stdio.h> int main( void ) { int result ; result=system("D:/DEV_FreeCAD/build/bin/box.step"); printf("%d",result); return 0; } So if anyone have idea please share with me. It will be a great help to me. Thanks for your kind help -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 18, 2020

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

by Pierce Ng

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

June 18, 2020

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

by Richard O'Keefe

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 > >

June 18, 2020

Re: [Pharo-users] DateTime now nanos

by Pierce Ng

On Wed, Jun 17, 2020 at 02:24:20AM -0500, Jeff Gray wrote: > I may be misunderstanding, but is the example in the link declaring a sqlite > column of type datetime? I didn't think you could do that. SQLite's typing is different from most other SQL engines. See https://sqlite3.org/datatype3.html. According to that document datetime is a valid column type. Indeed AFAICT any column type is allowed as long as it conforms to SQLite's naming requirements. When writing an instance of DateAndTime, Pharo-SQLite stores it as a string in the database. When reading, if the database indicates that the actual type of the value fetched is a string, Pharo-SQLite checks the column type declaration and turns the string back into a DateAndTime instance if the declared SQL column type is one of SQLite3Library dateTimeTypes. > I just created a person table with four text columns and wrote this in my > playground: > > |conn sql bindings| > conn := SQLite3Connection on: 'C:\Users\JeffGray\test.db'. > conn open. > sql := 'insert into person (active, created, first_name, last_name) values > ("Y", ?, "Jeff", "Gray")'. > bindings := OrderedCollection new. > bindings add: DateAndTime now. > conn execute: sql with: bindings. > conn close. I added table creation SQL with exactly one declared type of datetime to your example (slightly rewritten): | conn sql bindings | conn := SQLite3Connection openOn: '/tmp/dt.db'. [ conn execute: 'drop table person'. conn execute: 'create table person (active, created datetime, first_name, last_name)'. sql := 'insert into person (active, created, first_name, last_name) values ("Y", ?, "Jeff", "Gray")'. conn execute: sql value: DateAndTime now. ] ensure: [ conn close ]. Reading it back gives a DateAndTime instance. Previous mail I mentioned pluggablity. It turns out when one can declare any column type one has pluggability already. Below example declares the column 'created' as type 'unixtime' and writes the value 'DateAndTime now asUnixTime'. | conn sql bindings | conn := SQLite3Connection openOn: '/tmp/dt.db'. [ conn execute: 'drop table person'. conn execute: 'create table person (active, created unixtime, first_name, last_name)'. sql := 'insert into person (active, created, first_name, last_name) values ("Y", ?, "Jeff", "Gray")'. conn execute: sql value: DateAndTime now asUnixTime. ] ensure: [ conn close ]. Reading it backs gives an integer. The application programmer, knowing the column type declaration is unixtime, can then turn that into a DateAndTime instance. Pierce

June 18, 2020

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

by Jerry Kott

Norbert, let me join everyone in congratulating on this fantastic news, and wish your new company all success. Jerry Kott, OSCP Principal, Imageware Corporation <https://image-ware.com/> Security with Integrity. By Choice. By Design. This message has been digitally signed. PGP Fingerprint: A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5 > On Jun 17, 2020, at 15:19, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Hi Norbert, > > This is really good news for the community. > I wish you all the best for this initiative! > > Cheers, > > HernÃ¡n > > El miÃ©., 17 jun. 2020 a las 5:35, Norbert Hartl (<norbert(a)hartl.name <mailto:norbert@hartl.name>>) escribiÃ³: > Dear community, > > 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. > > We have been tinkering with the idea creating it for a long time. We talked to a lot of people, especially at last ESUG in cologne and finally decided to do it. So at the end of last year we founded the company PharoPro. Obstacles (one being covid-19) kept us from make it public until today. > > In close relationship with the pharo consortium our mission is to extend the market opportunities for pharo. > Although PharoPro is new and still small we want to show our commitment to the consortium and the community from the start. We decided therefor that PharoPro will join the pharo consortium as platinum member. > > Our plans apart from support contracts is to have an LTS (long term support) version of pharo, create a professional pharo ecosystem with libraries and frameworks and to help out building the infrastructure pharo needs. > > We are still shaping up. We want to know your requirements and needs that help us deciding what are the most needed things. So you might visit > > http://pharo-pro.com <http://pharo-pro.com/> > > and then come talk to us. > > Best regards and health, > > Norbert > PharoPro GmbH

June 18, 2020