September 2014 - Pharo-users

Re: [Pharo-users] FFI examples on Linux don't work

by phil＠highoctane.be

More on the story. So, the X11 example may not be the best one to have in FFI. It is interesting but complicated. A basic call, like: Sample class>>callC: aString <cdecl: short 'puts' (char*) module: '/lib/libc-2.12.so'> ^self externalCallFailed works nicely. Sample callC: 'Hello'. prints Hello on stdout. Phil On Mon, Sep 22, 2014 at 6:10 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I've been able to reproduce this. > > Well, my CentOS thing requires me for some reason to put > /usr/lib/libX11.so.6 in the module name (doing these kind of things looks > like usual for lib names with FFI from what I saw from old Squeak threads). > > > XCreateGC: xDisplay with: aDrawable with: valueMask with: values > <cdecl: X11GC 'XCreateGC' (X11Display* X11Drawable ulong long*) module: > '/usr/lib/libX11.so.6'> > > Now, other internal FFIPrims tests do work. > > So, it is X11 or something else, I do not know. > > Phil > > > On Mon, Sep 22, 2014 at 4:39 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> Annick Fron wrote: >> >>> Hi, >>> >>> I have posted a bug about this in fogbugz. >>> FFI example on Linux donât work >>> >>> X11Display coloredRectangles >>> raises an error Â« coud not coerce arguments Â». >>> In fogbugz, I was asked to raise this question in the mailing list, to >>> know if it comes from the VM or from FFI. >>> >>> Annick >>> >>> >>> >> Hi Annick, >> Sorry I don't know anything about this topic to help, just a minor >> observation that a link to the fogbugz issue would help streamline things >> for someone who does. >> :) >> cheers -ben >> >> >> >> >

Sept. 22, 2014

Versioneer. nice. mmMmmm...

by Ben Coman

While I had done the Versioneer tutorial some time ago, I had some inertial problem using it in anger. Now I'm happy to report using it just now to update the ConfigurationOfPharoLauncher was simple and smooth - which is great since I've never done a Configuration by hand. I thought it would be useful for others to see how simple it was... 1. Loaded latest ConfigurationOfPharoLauncher. 2. Loaded and tested newer PharoLauncher packages. 3. Opened World > Tools > Versioneer. 4. Selected PharoLauncher and <Open Project>. 5. Selected "development" list item. 6. Clicked <Release Version> and <Ok> to accept auto increment of version number. 7. Clicked <Commit the project> Now there is an updated ConfigurationOfPharoLauncher in its Smalltalkhub repository. Easy with Versioneer. mmMmmmm. nice. shiny..... cheers -ben

Sept. 22, 2014

Re: [Pharo-users] FFI examples on Linux don't work

by phil＠highoctane.be

I've been able to reproduce this. Well, my CentOS thing requires me for some reason to put /usr/lib/libX11.so.6 in the module name (doing these kind of things looks like usual for lib names with FFI from what I saw from old Squeak threads). XCreateGC: xDisplay with: aDrawable with: valueMask with: values <cdecl: X11GC 'XCreateGC' (X11Display* X11Drawable ulong long*) module: '/usr/lib/libX11.so.6'> Now, other internal FFIPrims tests do work. So, it is X11 or something else, I do not know. Phil On Mon, Sep 22, 2014 at 4:39 PM, Ben Coman <btc(a)openinworld.com> wrote: > Annick Fron wrote: > >> Hi, >> >> I have posted a bug about this in fogbugz. >> FFI example on Linux donât work >> >> X11Display coloredRectangles >> raises an error Â« coud not coerce arguments Â». >> In fogbugz, I was asked to raise this question in the mailing list, to >> know if it comes from the VM or from FFI. >> >> Annick >> >> >> > Hi Annick, > Sorry I don't know anything about this topic to help, just a minor > observation that a link to the fogbugz issue would help streamline things > for someone who does. > :) > cheers -ben > > > >

Sept. 22, 2014

Re: [Pharo-users] Glamour question

by Werner Kassens

Hi Andrei, oh yes, that answers my question exactly, thank you! > Now accessing the bindings of a playground seems like a useful use-case. > I'll look to see if I can add a nicer api for this. i agree, otoh <grin> even workspace doesnt have one, as i have to use #instVarNamed:. werner

Sept. 22, 2014

Re: [Pharo-users] Glamour question

by Andrei Chis

Hi Werner, If all you have in the window is the playground then this should give you the bindings: (window findDeeplyA: RubEditingArea) model variableBindings I know it's not pretty but it works. Now accessing the bindings of a playground seems like a useful use-case. I'll look to see if I can add a nicer api for this. Cheers, Andrei On Mon, Sep 22, 2014 at 4:46 PM, Werner Kassens <wkassens(a)libello.com> wrote: > Hi, > if i want to have access to the variables in a workspace and know its > window i simply do: > window model instVarNamed: 'bindings' > now i'd like to know how i do something like that with a GTPlayground that > resides in a GLMSystemWindow > werner > >

Sept. 22, 2014

Glamour question

by Werner Kassens

Hi, if i want to have access to the variables in a workspace and know its window i simply do: window model instVarNamed: 'bindings' now i'd like to know how i do something like that with a GTPlayground that resides in a GLMSystemWindow werner

Sept. 22, 2014

Re: [Pharo-users] FFI examples on Linux don't work

by Ben Coman

Annick Fron wrote: > Hi, > > I have posted a bug about this in fogbugz. > FFI example on Linux donât work > > X11Display coloredRectangles > > raises an error Â« coud not coerce arguments Â». > In fogbugz, I was asked to raise this question in the mailing list, to know if it comes from the VM or from FFI. > > Annick > > Hi Annick, Sorry I don't know anything about this topic to help, just a minor observation that a link to the fogbugz issue would help streamline things for someone who does. :) cheers -ben

Sept. 22, 2014

Re: [Pharo-users] Ubuntu Font License : Compatibility with Pharo License?

by Henrik Johansen

On 19 Sep 2014, at 9:46 , Mayuresh Kathe <mayuresh(a)kathe.in> wrote: > Would the Ubuntu Font License at; http://font.ubuntu.com/licence/ be considered compatible with the Pharo license? > > If it is not _compatible_ would the usage of Ubuntu fonts still be acceptable/permissible within Pharo? > > Thanks, > > ~Mayuresh Pharo is MIT, you can do what you want with it. If you mean compatible in the sense that you may a) Make a loadable package which honours the UFL, which can be loaded and used in a Pharo image b) Put the Freetype font files alongside your image (along with licensing notice), and set it as your default font then yes, it is compatible. What I don't think could be done, is embed them in a distributed Pharo release, since UFL specifically prohibits relicensing, and it's a goal to keep the distribution itself as MIT, not MIT "with certain parts under the UFL". Nothing stops you from doing that in an image you intend to distribute yourself though, because hey, MIT. Cheers, Henry

Sept. 22, 2014

FFI examples on Linux don't work

by Annick Fron

Hi, I have posted a bug about this in fogbugz. FFI example on Linux donât work X11Display coloredRectangles raises an error Â« coud not coerce arguments Â». In fogbugz, I was asked to raise this question in the mailing list, to know if it comes from the VM or from FFI. Annick

Sept. 22, 2014

Re: [Pharo-users] Pharo Glorp 1.7 <-> VisualWorks

by Mariano Martinez Peck

On Fri, Sep 5, 2014 at 6:53 AM, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com > wrote: > I have no idea how complicated this can be. I'm a bit reluctant to dive > into this if we are only 2-3 people to use Glorp in Pharo. > > Guillermo, Mariano, what was the process when you imported Glorp in the > first place? How did you keep up with Glorp latest changes (From what I see > in Store, development is not too active)? > > It was a bit complicated. First off, Guille exported all Glorp packages from stone using the "file out" format. These fileout would no import directly into Pharo as I remember, some human or script changes were needed to that these file out could be imported in Pharo. These code was ported under the package Glorp inside our repo. Then the second step was to apply all our changes to Glorp since our changes are not integrated in main stone repostories. These changes are PharoDatabaseAccessor, DatabaseDriver, some changes to Login class and a few other things AFAIK. The third part, was either our special subclass of DatabaseDriver, for either native postgres driver or dbx driver. All that together became GlorpDBX. >From which glorp version we did that port to Pharo, I don't remember and I cannot seem to find it in my old mails. If someone wants to go through these again, then I think you should spend the time so that our changes are integrated in main trunk. Otherwise, future ports will again be a pain. Cheers, > > On Fri, Sep 5, 2014 at 11:30 AM, Stephan Eggermont <stephan(a)stack.nl> > wrote: > >> Sven wrote: >> >Porting something cross platform is a huge amount of work, I think most >> of it was basically done by hand. >> >This creates a huge maintenance problem of course. The same is true for >> Xtreams. >> >Seaside seems to be able to manage this problem by being extremely >> careful. >> >> We now have the infrastructure in place (CI) that supports a much better >> approach. >> We could use a vw image to download the current version from the public >> store >> and generate the platform-independent mczs from there. That of course >> requires >> changes to the VW code base to create and use platform classes. That is >> similar to >> what we did in the other direction with Parasol, what Roassal does and >> Seaside. >> If we make the (namespace) transformations explicit, we should be able to >> sync >> in two directions. >> >> Stephan >> >> >> >> > -- Mariano http://marianopeck.wordpress.com

Sept. 22, 2014