- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] NBOpenGL update

by Dan Corneanu

Ok, I have fixed those problems but now I stumbled on other problems. If I load the latest version ConfigurationOfNBOpenGL project lastVersion load. When I try to run the demo I get a SubscriptOutOfBounds:2083 exception at NBOpenGLAPIBase>>emitCall: generator: If I load version 1.0.2 (ConfigurationOfNBOpenGL project version: '1.0.2') load. and try the demo I get 'Error: Frame buffer is incomplete: GL_FRAMEBUFFER_UNSUPPORTED' in NBGLFrameBuffer>>checkStatus By the way, I am on a windows machine. On Sat, Jan 5, 2013 at 9:34 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 5 January 2013 11:29, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: > > Hello, > > I have loaded the latest NBOpenGL into Pharo 1.4 but when I try > > GLTTRenderingDemo new openInWorld. > > I get a > > SmallInteger(Object)>>doesNotUnderstand: #| > > > > What am I missing/doing wrong? > > > this is an extension method, which looks like i missed when splitting > package.. > it is synonym for #bitOr: > > > Best regards, > > Dan. > > > > P.S. > > There is also a typo in: > > NBMacGLContextDriver >> supportsCurrentPlatform > > "NativeBoostConstants mac32PlaformId" I think it should be > > "NativeBoostConstants mac32PlatformId" > > > yes. > Should fix it :) > > > > > > > On Fri, Apr 6, 2012 at 3:31 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> Hi there, > >> > >> for those, who interested, i updated a NBOpenGL configuration. > >> > >> Changes are: > >> > >> - updated GL API to most recent available (taken directly from opengl > >> specs). Now there is about 300 more methods to explore :) > >> - finally dealt with win32 support code and made it working again > >> - fixed the GLX function prefix , which should be 'glX' not 'glx' > >> > >> To load it in 1.4 use: > >> > >> Gofer new > >> squeaksource: 'NBOpenGL'; > >> package: 'ConfigurationOfNBOpenGL'; > >> load. > >> > >> > >> and then > >> > >> (ConfigurationOfNBOpenGL project version: '1.0.2') load > >> > >> I did not tested the update thoroughly.. so i would appreciate if > >> people will try it out and tell how it goes. > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

Jan. 5, 2013

Re: [Pharo-project] [ANN] NBOpenGL update

by Igor Stasenko

On 5 January 2013 11:29, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: > Hello, > I have loaded the latest NBOpenGL into Pharo 1.4 but when I try > GLTTRenderingDemo new openInWorld. > I get a > SmallInteger(Object)>>doesNotUnderstand: #| > > What am I missing/doing wrong? > this is an extension method, which looks like i missed when splitting package.. it is synonym for #bitOr: > Best regards, > Dan. > > P.S. > There is also a typo in: > NBMacGLContextDriver >> supportsCurrentPlatform > "NativeBoostConstants mac32PlaformId" I think it should be > "NativeBoostConstants mac32PlatformId" > yes. Should fix it :) > > > On Fri, Apr 6, 2012 at 3:31 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> Hi there, >> >> for those, who interested, i updated a NBOpenGL configuration. >> >> Changes are: >> >> - updated GL API to most recent available (taken directly from opengl >> specs). Now there is about 300 more methods to explore :) >> - finally dealt with win32 support code and made it working again >> - fixed the GLX function prefix , which should be 'glX' not 'glx' >> >> To load it in 1.4 use: >> >> Gofer new >> squeaksource: 'NBOpenGL'; >> package: 'ConfigurationOfNBOpenGL'; >> load. >> >> >> and then >> >> (ConfigurationOfNBOpenGL project version: '1.0.2') load >> >> I did not tested the update thoroughly.. so i would appreciate if >> people will try it out and tell how it goes. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Jan. 5, 2013

Re: [Pharo-project] [ANN] NBOpenGL update

by Dan Corneanu

Hello, I have loaded the latest NBOpenGL into Pharo 1.4 but when I try GLTTRenderingDemo new openInWorld. I get a SmallInteger(Object)>>doesNotUnderstand: #| What am I missing/doing wrong? Best regards, Dan. P.S. There is also a typo in: NBMacGLContextDriver >> supportsCurrentPlatform "NativeBoostConstants mac32PlaformId" I think it should be "NativeBoostConstants mac32PlatformId" On Fri, Apr 6, 2012 at 3:31 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi there, > > for those, who interested, i updated a NBOpenGL configuration. > > Changes are: > > - updated GL API to most recent available (taken directly from opengl > specs). Now there is about 300 more methods to explore :) > - finally dealt with win32 support code and made it working again > - fixed the GLX function prefix , which should be 'glX' not 'glx' > > To load it in 1.4 use: > > Gofer new > squeaksource: 'NBOpenGL'; > package: 'ConfigurationOfNBOpenGL'; > load. > > > and then > > (ConfigurationOfNBOpenGL project version: '1.0.2') load > > I did not tested the update thoroughly.. so i would appreciate if > people will try it out and tell how it goes. > > > -- > Best regards, > Igor Stasenko. > >

Jan. 5, 2013

[Pharo-project] broken builds

by Camillo Bruni

looks like the latest image/vm combination makes the command-line fail... On the Ci server I cannot run any command-line tools anymore with the latest.zips :/ On the Mac: - latest stack VM fails to open latest 20 image - latest cog VM fails to open latest 20 image - latest pharo VM fails to open latest 20 image with an older cog VM I can open the image without issues: Smalltalk vm version 'CoInterpreter VMMaker-oscog-IgorStasenko.162 uuid: e4554f9a-cc90-4826-a807-ac282b782fe4 Jul 26 2012 saving the image with the old VM immediately makes it work with the latest vms :?

Jan. 4, 2013

[Pharo-project] zero conf scripts location

by Camillo Bruni

I plan to move the ci-zero conf scripts to a new subdirectory http://pharo.gforge.inria.fr/ci/script/* instead of http://pharo.gforge.inria.fr/ci/* is anyone besides our ci servers using theses scripts? best cami

Jan. 4, 2013

Re: [Pharo-project] NativeBoost design and deployment

by Marcus Denker

On Jan 4, 2013, at 9:56 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 4 January 2013 09:51, Torsten Bergmann <astares(a)gmx.de> wrote: >>> yes it needs sources (indirectly) to bind method's argument names >>> during code generation. >> >> Sad. So this is currently a showstopper in using NB >> in deployments where one would not like to give the >> sources away. >> >> If we want (commercial) developers to write applications >> in Pharo there should be a fix for that. >> > Yes. I don't like it either. It needs only the arg names (and their order) > and for that, it involves a compiler to parse source and generate AST. > Which can be completely avoided if temp names is stored somewhere > after compilation. We need a higher level model of code then what CompiledMethods can give us. There is always the question if now, where even a $25 computer has 256MB of RAM, one should not revisit the design decisions that people took in the 30 or even 40 years ago... Marcus

Jan. 4, 2013

Re: [Pharo-project] NativeBoost design and deployment

by Igor Stasenko

On 4 January 2013 09:51, Torsten Bergmann <astares(a)gmx.de> wrote: >> yes it needs sources (indirectly) to bind method's argument names >> during code generation. > > Sad. So this is currently a showstopper in using NB > in deployments where one would not like to give the > sources away. > > If we want (commercial) developers to write applications > in Pharo there should be a fix for that. > Yes. I don't like it either. It needs only the arg names (and their order) and for that, it involves a compiler to parse source and generate AST. Which can be completely avoided if temp names is stored somewhere after compilation. > Thanks > T. -- Best regards, Igor Stasenko.

Jan. 4, 2013

[Pharo-project] NativeBoost design and deployment

by Igor Stasenko

On 4 January 2013 08:54, Torsten Bergmann <astares(a)gmx.de> wrote: > When one deploys an image one usually requires ONLY > the image - not the source or changes file. An "image locker" > code would look like this: > > SmalltalkImage checkSourcesFileAvailability: false. > SmalltalkImage checkChangesFileAvailability: false > > do disable acording warnings when source/changefile is removed. > > If one uses NativeBoost in such a deployment scenario, for > instance the > > NBWin32Shell shellBrowse: 'http://www.google.de' > > functionality the internal code (due to missing source) now > looks like this > > shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5 > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll' > > Hence the t1 ... t5 parameters. > > NativeBoost is in this situation not able to match the > FFI parameters and throws an error "Could not find accessor for variable ..." > > Try yourself without a changes and source file. This makes > NativeBoost not very deployment friendly and unusable in > such a "minimal deployment" scenario ... > > Any comments? > yes it needs sources (indirectly) to bind method's argument names during code generation. To avoid that, i can imagine that one must modify a compiler to detect if compiled method primitive requires arg names, and store them in method properties. Like that later code generator can use them without need to access the source code. > Thanks > T. -- Best regards, Igor Stasenko

Jan. 4, 2013

[Pharo-project] NativeBoost design and deployment

by Torsten Bergmann

When one deploys an image one usually requires ONLY the image - not the source or changes file. An "image locker" code would look like this: SmalltalkImage checkSourcesFileAvailability: false. SmalltalkImage checkChangesFileAvailability: false do disable acording warnings when source/changefile is removed. If one uses NativeBoost in such a deployment scenario, for instance the NBWin32Shell shellBrowse: 'http://www.google.de' functionality the internal code (due to missing source) now looks like this shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5 <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll' Hence the t1 ... t5 parameters. NativeBoost is in this situation not able to match the FFI parameters and throws an error "Could not find accessor for variable ..." Try yourself without a changes and source file. This makes NativeBoost not very deployment friendly and unusable in such a "minimal deployment" scenario ... Any comments? Thanks T.

Jan. 4, 2013

Re: [Pharo-project] [squeak-dev] Mine-able ideas?

by Igor Stasenko

On 3 January 2013 02:55, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Wed, Jan 02, 2013 at 05:26:25PM -0800, tim Rowledge wrote: >> >> On 02-01-2013, at 4:15 PM, "David T. Lewis" <lewis(a)mail.msen.com> wrote: >> > >> > Do you have a reference to the sensible compiled method format? I think >> > I recall some discussions on that topic, but I don't recall when or by >> > whom. >> >> I was thinking of the now-ancient 'NewCompiledMethod', going back to about 1997. The last I heard on the subject was about 5 years ago. > > Ah, right, it's all coming back to me now. Thanks. > >> But.. >> > >> > But really, what are we missing? We have CompiledMethodTrailer that appears to >> > provide an infinitely extensible mechanism for inventing new kinds of source >> > pointers. >> >> ? it reads as if that might provide the same result. Namely having the source pointer for each method be a proper oop, with all the obvious advantages over a weirdly encrypted 24bit number hidden within some bytes at the end of a byte array >> > > In principle, I think yes. Igor Stasenko created the CompiledMethodTrailer, > which has provided a really nice way to keep the existing formats working while > allowing all sorts of extensions. I'm not sure if he had in mind to implement > source pointers as first class objects, but it seems like it would be a > straightforward extension. > Sure thing, i wanted to go forward. I wrote about it multiple times. But we need someone who will put an idea into flesh :) > Cross posting to pharo in order to lure Igor back into the discussion ;-) > > Dave -- Best regards, Igor Stasenko.

Jan. 3, 2013