March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Some love to NBOpenGL (making it up-to-date with pharo 2.0)

by Igor Stasenko

On 14 March 2013 21:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-03-14, at 19:48, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 14 March 2013 18:46, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> Do not forget to create a jenkins job on https://ci.inria.fr/pharo-contribution/ >>> >> https://ci.inria.fr/pharo-contribution/job/NBOpenGL/ > > perfect! far .. quite far from. NBOpenGL begs for more love... but my love time is scheduled for something else. :) -- Best regards, Igor Stasenko.

March 14, 2013

Re: [Pharo-project] [bug] window graphical leftovers

by Serge Stinckwich

I have the same problem. Mac OS X 10.8.2 / MBP Retina. Regards, On Thu, Mar 14, 2013 at 9:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > On Mac, when I move a window downwards I get some leftovers on the background (see picture from https://dl.dropbox.com/u/18323746/Tmp/window-graphical-leftovers.png) > > I am using the latest Pharo 2.0 and Pharo VM (updated every day). > > Am I the only one to see this? > > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/

March 14, 2013

[Pharo-project] triggering jenkins when committing to smalltalkhub

by Tudor Girba

Hi, Is there a way to get Jenkins trigger a build when we commit something to SmalltalkHub? Cheers, Doru -- www.tudorgirba.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

March 14, 2013

Re: [Pharo-project] [ANN] Some love to NBOpenGL (making it up-to-date with pharo 2.0)

by Camillo Bruni

On 2013-03-14, at 19:48, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 14 March 2013 18:46, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> Do not forget to create a jenkins job on https://ci.inria.fr/pharo-contribution/ >> > https://ci.inria.fr/pharo-contribution/job/NBOpenGL/ perfect!

March 14, 2013

[Pharo-project] Pharo Contribution Example Job

by Camillo Bruni

I added some documentation for the pharo-contribution jenkins: https://ci.inria.fr/pharo-contribution/ and specially https://ci.inria.fr/pharo-contribution/job/JobTemplate/? So whenever you create a new job, base it on the JobTemplate.

March 14, 2013

[Pharo-project] [bug] window graphical leftovers

by Tudor Girba

Hi, On Mac, when I move a window downwards I get some leftovers on the background (see picture from https://dl.dropbox.com/u/18323746/Tmp/window-graphical-leftovers.png) I am using the latest Pharo 2.0 and Pharo VM (updated every day). Am I the only one to see this? Cheers, Doru -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

March 14, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Igor Stasenko

On 14 March 2013 19:01, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Yes. RTL is essentially an assembler for an abstract machine with readable > names for registers. Arguably the Cog back-end assembler is an RTL. It has > abstract registers (ReceiverResultReg, ClassReg etc), and abstract > operations (e.g. MoveR:R:). To do marshalling you need only define argument > registers (floating-point and integer, an empty set on the x86), return > registers, the stack pointer, and maybe the frame pointer, plus a basic set > of data manipulation instructions. Then either define these as numeric > constants so that the JIT interprets sequences of numbers, or strings, so > that the JIT uses string matching (the former is of course faster and > slimmer). The JIT maps these abstract instructions and register names into > concrete machine code and register numbers. > [snip] yes.. this definition fits quite well with what we're working on.. thanks for pointer(s). -- Best regards, Igor Stasenko.

March 14, 2013

Re: [Pharo-project] [ANN] Some love to NBOpenGL (making it up-to-date with pharo 2.0)

by Igor Stasenko

On 14 March 2013 18:46, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Do not forget to create a jenkins job on https://ci.inria.fr/pharo-contribution/ > https://ci.inria.fr/pharo-contribution/job/NBOpenGL/ > On 2013-03-14, at 16:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> cool :) >> >> On Mar 14, 2013, at 4:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Hi, there >>> >>> since Pharo 2.0 is out (well almost ;) ) , it is time to update >>> configuration of stuff .. >>> today the prize goes to NBOpenGL project (Athens tomorrow).. >>> >>> I did not much, just boring things: >>> >>> - migrated all packages on smalltalkhub >>> (http://www.smalltalkhub.com/#!/~PharoExtras/NBOpenGL) from >>> squeaksource. >>> - updated configuration(s). I removed explicit dependency from >>> NativeBoost, since it is in 2.0 by default. >>> - rescued a legacy TrueType package, which was thrown out of base >>> image, so i took a freedom to put it in NBOpenGL repository, >>> because it seems only my demo code does something with it :) >>> >>> If you wanna try if it works, do: >>> >>> 1. >>> Gofer it >>> smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; >>> package: 'ConfigurationOfNBOpenGL'; >>> load. >> >> easier: >> >> Gofer it >> smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; >> configurationOf: 'NBOpenGL'; >> load. >> >> :) >> >>> >>> 2. >>> (ConfigurationOfNBOpenGL project version: '2.0') load >>> >>> >>> 2.1. If VM crashes when doing step 2. Download the stable one from >>> [http://pharo.gforge.inria.fr/ci/vm/pharo/] >>> and repeat step 2. (Many many thanks to Esteban who was persistent >>> enough ditching this problem finally!!!!!!!!!!!!!!) >>> 2.2. if VM still crashes, you know who to blame ;) >> >> not blame, but report :) >> I cannot preview all the possible issues, you know... I just fixed all the crashes that I have reported :P >> >> Esteban >> >>> >>> 3. >>> GLTTRenderingDemo new openInWorld >>> >>> (if it works you shall see some strange Cyrillic (no, it is not >>> Klingon) letters zooming in and out again in a loop :) >>> >>> >>> 4. If you on windows or linux, report problems. Because i did not >>> tried it there. ;) >>> But for me it was a great relief to see it working at least on my Mac >>> after many perturbations with 2.0 and NativeBoost over past half-year. >>> >>> P.S. ah.. yeah.. if you try to run demo on very old crappy hardware >>> with very old opengl drivers, don't blame anyone that it doesn't >>> works, except yourself :) As far as i remember demo requires at least >>> OpenGL 2.0 support. But this is just a demo, if it doesn't works, it >>> doesn't immediately means that you cannot use nativeboost opengl >>> bindings in your own project and make things work properly for older >>> versions of opengl. >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > -- Best regards, Igor Stasenko.

March 14, 2013

[Pharo-project] fogbugz feature requests

by Camillo Bruni

Apparently fogbugz has their own nice stackexchange instance (I still wanted that for pharo). And there is a nice feature request to list related bugs if you report one, something I have been missing for a while at the google issue tracker. And something I ran into a couple of times myself by not searching for other bugs first. so vote up! http://fogbugz.stackexchange.com/questions/5318/feature-request-discourage-…

March 14, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Eliot Miranda

On Thu, Mar 14, 2013 at 7:20 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > > On Mar 13, 2013, at 7:11 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > On Tue, Mar 12, 2013 at 7:54 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 12 March 2013 19:44, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> >> > 3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons >> and >> > c) new FileSystem primitives. >> > a) is cool, but I don't like the x86 specificity. I want a >> cross-platform >> > FFI, so I'm not excited enough to include NB in my port. >> >> Just let me remind you that (x86 specificity) is completely on image side. >> The VM side changes are minimal and 100% not platform specific. >> Making NB image-side implementation platform-unspecific is another story.. >> but as i said before i see no reason to do it unless there's a version >> of Cog which runs >> on some other platform :) >> > > I understand that. I think Squeak should provide a platform-independent > FFI at the image level. > > >> >> There is plans and some work started on getting there, by making a >> platform-neutral low-level >> DSL, which can be used for generating native code. >> > > This is called RTL ;) > > > I never hear about it... you mean > http://en.wikipedia.org/wiki/Register_transfer_language ? > If so, looks interesting :) > Yes. RTL is essentially an assembler for an abstract machine with readable names for registers. Arguably the Cog back-end assembler is an RTL. It has abstract registers (ReceiverResultReg, ClassReg etc), and abstract operations (e.g. MoveR:R:). To do marshalling you need only define argument registers (floating-point and integer, an empty set on the x86), return registers, the stack pointer, and maybe the frame pointer, plus a basic set of data manipulation instructions. Then either define these as numeric constants so that the JIT interprets sequences of numbers, or strings, so that the JIT uses string matching (the former is of course faster and slimmer). The JIT maps these abstract instructions and register names into concrete machine code and register numbers. Note that the RTL still has platform-specific constructs, e.g. a LinkReg is valid on RISCs but meaningless on x86, and the ABI-to-RTL compiler has all the knowledge about the format of outgoing calls, what kinds of registers are available (address, data, floating-point, etc). But it does not have to do the final assembly step, fixing up branches etc. This is low-level work the JIT already does and needs to do itself because it knows at what addresses code is generated at. P.S. that wikipedia page is rather poor. Another example other than GCC's is Ralph Johnson's and Carl McConnell's "The *RTL* System: A Framework for Code Optimization<http://www.google.com/url?sa=t&rct=j&q=ralph%20johnson%20rtl&source=web&cd=…> ". > Esteban > > > >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > best, > Eliot > > > -- best, Eliot

March 14, 2013