Opengl and Squeak

> Am 16.08.2012 19:17, schrieb kilon:
>> Is there a library out there for squeak that will allow me to use opengl 4 ?
>>
>>
> I think you should be able to extend the existing OpenGL interface with the OpenGL 4 functions that you want to access.
> But AFAIK no one has done it yet.
>
> Cheers,
> Hans-Martin
>
>

> The Squeak OpenGL bindings are on squeaksource.com. Here is an older
> mail exchange describing the installation procedure:
> http://forum.world.st/OpenGL-in-4-1-or-later-td3794639.html I have
> just tried it in a 4.3 image, and after fixing three small glitches it
> worked: - somehow the method OGLUnix>>#openGLLibraryName has an
> illegal character at the end (it's probably being handled as
> whitespace in other Squeak/Pharo images) - the method Point>>#area
> does not exist. I implemented it as returning x*y, which works. - the
> method printShowingMaxDecimalPlaces: does not exist. I used
> printString instead. That should get you started. Cheers, Hans-Martin

> Well if FFI works okish in squeak I dont have a need for nativeboost, since I prefer to code in smalltalk than assembly.?
>
> I decided to continue my project 'Ephestos' is squeak, since Blender python has been a complete failure, the opengl implementation is buggy , still stuck to version 1.1 and it consumes CPU cycles like crazy (simple hand morph system ?consume 50% of my dual core) so fingers crossed it will works with squeak. I dont care for fancy features like nativevboost if its buggy, non cross platform and slow.?
>
> Seems I am not getting replies from other than you lawson , I assume something is wrong with my squeak-dev subscription.?
>
> Anyway, will test FFI from CroquetGL and hopefully it will work for me too.Thanks for the help.?
>
> ________________________________
>  From: Lawson English <[hidden email]>
> To: [hidden email]
> Sent: Thursday, 16 August 2012, 23:07
> Subject: Re: [squeak-dev] Opengl and Squeak
>  
> thanks Hans-Martin. I'll update my videos with that bit of info too.
>
> I have been playing quite a bit with NativeBoost lately and it offers some very nice features that anyone wanting to make a game or other realtime-ish application will find beneficial, including the ability to create a "cascade" of foreign file calls within a single method, or even program a bit of custom x86 assembler. I don't know what will be involved to port it to Squeak, but Igor's talk suggests that the only "special" bit is already present in the VM, which should work with either Pharo or Squeak. The rest is just glue code at the Smalltalk level, which means that it is perfectly doable to get it working on Squeak, in theory at least.
>
> Native boost also offers a way of passing an arbitrary? ByteArray to an external function as though it were a normal pointer to a bit of malloc-ed memory, which can be VERY useful with certain libraries, that and the ability to actually malloc memory for a ByteArray from the OS level heap, opens up all sorts of possibilities like having an external lib render directly into a BitMap object asynchronously from its own OS level thread so that each update can show the library's progress in a morph without any further coding.
>
> I'm actually working on a simple MandelBrot Set generator lib in C to demo this.
>
> L.
>
>
>
> On 8/16/12 12:38 PM, Hans-Martin Mosner wrote:
> > The Squeak OpenGL bindings are on squeaksource.com. Here is an older mail exchange describing the installation procedure: http://forum.world.st/OpenGL-in-4-1-or-later-td3794639.html I have just tried it in a 4.3 image, and after fixing three small glitches it worked: - somehow the method OGLUnix>>#openGLLibraryName has an illegal character at the end (it's probably being handled as whitespace in other Squeak/Pharo images) - the method Point>>#area does not exist. I implemented it as returning x*y, which works. - the method printShowingMaxDecimalPlaces: does not exist. I used printString instead. That should get you started. Cheers, Hans-Martin
>
>
> -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner).
> https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all
>

> I decided to continue my project 'Ephestos' is squeak, since Blender python
> has been a complete failure, the opengl implementation is buggy , still
> stuck to version 1.1 and it consumes CPU cycles like crazy (simple hand
> morph system  consume 50% of my dual core) so fingers crossed it will works
> with squeak. I dont care for fancy features like nativevboost if its buggy,
> non cross platform and slow.
>
> Seems I am not getting replies from other than you lawson , I assume
> something is wrong with my squeak-dev subscription.
>
> Anyway, will test FFI from CroquetGL and hopefully it will work for me
> too.Thanks for the help.
> ________________________________
> From: Lawson English <[hidden email]>
> To: [hidden email]
> Sent: Thursday, 16 August 2012, 23:07
>
> Subject: Re: [squeak-dev] Opengl and Squeak
>
> thanks Hans-Martin. I'll update my videos with that bit of info too.
>
> I have been playing quite a bit with NativeBoost lately and it offers some
> very nice features that anyone wanting to make a game or other realtime-ish
> application will find beneficial, including the ability to create a
> "cascade" of foreign file calls within a single method, or even program a
> bit of custom x86 assembler. I don't know what will be involved to port it
> to Squeak, but Igor's talk suggests that the only "special" bit is already
> present in the VM, which should work with either Pharo or Squeak. The rest
> is just glue code at the Smalltalk level, which means that it is perfectly
> doable to get it working on Squeak, in theory at least.
>
> Native boost also offers a way of passing an arbitrary  ByteArray to an
> external function as though it were a normal pointer to a bit of malloc-ed
> memory, which can be VERY useful with certain libraries, that and the
> ability to actually malloc memory for a ByteArray from the OS level heap,
> opens up all sorts of possibilities like having an external lib render
> directly into a BitMap object asynchronously from its own OS level thread so
> that each update can show the library's progress in a morph without any
> further coding.
>
> I'm actually working on a simple MandelBrot Set generator lib in C to demo
> this.
>
> L.
>
>
>
> On 8/16/12 12:38 PM, Hans-Martin Mosner wrote:
>> The Squeak OpenGL bindings are on squeaksource.com. Here is an older mail
>> exchange describing the installation procedure:
>> http://forum.world.st/OpenGL-in-4-1-or-later-td3794639.html I have just
>> tried it in a 4.3 image, and after fixing three small glitches it worked: -
>> somehow the method OGLUnix>>#openGLLibraryName has an illegal character at
>> the end (it's probably being handled as whitespace in other Squeak/Pharo
>> images) - the method Point>>#area does not exist. I implemented it as
>> returning x*y, which works. - the method printShowingMaxDecimalPlaces: does
>> not exist. I used printString instead. That should get you started. Cheers,
>> Hans-Martin
>
>
> -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk
> for the (almost) complete and compleate beginner).
> https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all
>
>
>
>
>
>
>

> On Sat, Aug 18, 2012 at 08:19:34AM +0100, dimitris chloupis wrote:
>
> Hi Dimitris,
>
> Skip to the bottom for the important part, how to build plugins.
>
> But first I will try to answer your questions.
>
>> Why coders prefer FFIs ??
>>
> Some people prefer FFIs because it allows the interface to be done
> without using compilers or building VMs, and because it is not necessary
> to distribute a compiled plugin to provide the platform interface.
>
> Some people may prefer using an FFI because they think it will save
> time. They are usually wrong. Unfortunately, by the time they figure
> this out, they will have wasted a lot of time trying to do things the
> "easy way", and never bothered to invest a few hours to learn how to
> do it more reliably with a plugin.
>
>> For example I am a python coder, ctypes which is the FFI cpython comes with has seen an explosion the last years . The most suprising is the conversion of pyOpeng from C extenstion to ctypes libraries even though that has slow down the library 2-3x times. The reason behind that move is not hard to guess. Much easier to maintain. FFIs remove one importan element from the equation and pretty much why people avoid using C in the first place. Compiling and building. Thus making FFIs ideals for the fast changing libraries , be able to change things on the fly and not have to suffer the slow downs of the C compiler.?
>>
> Yes, an FFI is very adaptable because all changes can be done in the image,
> and that is a good thing. However, relying on the compiler is only a
> problem if you are waiting for someone *else* to compile it for you.
> If you are willing to learn to do it for yourself, it is actually very
> fast and easy to make updates. And if you do most of your work in Smalltalk
> (aka "slang"), you will manage it with the same version control and tools
> that you use for all the rest of your Smalltalk work.
>
> You will find that you have far better support for debugging and profiling
> when you use a plugin, because you can use the platform debuggers and other
> tools directly. Also (and this is a really big thing in practice), you
> have the benefits of strong type checking provided by the C compiler when
> you build the interface as a plugin rather than directing your calls through
> an FFI interface.
>
>> I have taken a look at VM plugins, glanced through some tutorials, if I am not mistaken Slang is used to produce C code that then is compiled in a form that can be loaded by the VM is a primitive. The like an FFI call , you just use the primitive to execute the action.?
>>
> Yes, that's right.
>
>> I am definetly interested , and if you have any link I am more than welcome them, my only hesitation is buidling C files . I am the type of coder that likes to moves one line of code (or several ) per time and always make sure by testing that I dont code garbage. One of the reason I decided to convert from python to squeak was because I felt that it was easier to "live code" in this enviroment. I fear that a VM plugin might cut short this experience. Please correct me If I am mistaken.?
>>
> See below for instructions that should help get you started. My explanation
> assumes you are using unix/Linux, so please let me know if you are on
> Windows or Mac or something else.
>
>> Saying that I have installed with ease CroquetGL and the opengl example seems to run fine, (exampletex fails but that is to be expected , have not tried the fix yet).?
>>
>> If VM plugins are more stable, reliable and what the squeak community prefers I have no issues going down that route.?
>>
> You will probably not get a consensus from the community. I am giving you
> an opinion based on my own personal experience.
>
> OK, with that out of the way, here is what you should do:
>
> Allow about two hours to work through these instructions for the first time.
> If you are using Linux or Unix, you can follow the steps exactly. If you
> use another platform, just do the things you can, and you will still be able
> to get an idea of how things works. Here are the steps to follow:
>
> Prepare tools. On Linux, install dev tools, libraries of interest, and Subversion.
>
> Get a copy of the platform sources. Do this in the same directory in which
> you will be running your Squeak image. On Linux:
>
>    $ svn co http://squeakvm.org/svn/squeak/trunk/platforms
>
> Any recent Squeak image will work for building VMs, but I like to work with
> an updated trunk image, like this:
>
>    world -> open... -> morphic project
>    (enter the project)
>    [menu bar] Tools -> Preferences
>    (select category Monticello. change Update URL from http://source.squeak.org/squeak43 to http://source.squeak.org/trunk.
>      accept the change (<ctl> s). click save button)
>    world -> help... -> update code from server
>    (wait for update process to complete, then save your image)
>
> Install VMMaker. This is the trunk version for an interpreter VM. Do it this way
> to get started so that you will be able to see your generated C code in a browser.
>
>    world -> open... Squeak Map Catalog
>    in the Squeak Map browser, click Update

>    select package VMMaker, version "head"
>    click Install
>    (wait for installation to complete)
>
>    In a workspace, evaluate "VMMaker initialize". This will activate the Slang browsing tools.
>    (note: in the future, you can evaluate "VMMaker updateFromServer" to keep your VMMaker up to date)
>
> Now have a look at some plugins.
>
> Open a browser on UnixOSProcessPlugin>>primitiveGetUid. This is a simple
> primitive call that links to the getuid() function in the C runtime library,
> and answers your uid when the primitive is called. This is how the primitive
> looks in Smalltalk. There is no C support code required, just the Smalltalk
> code that you see here.

> While looking at the primitiveGetUid method, click the "source" button on
> the browser, then select either "translate inlined C". You will now see
> the C code for the primitive.
>
> Explore a few more primitives and other methods, and have a look at other
> plugins, looking at both the Smalltalk source code and the generated C code.
>
> Now point your browser at B3DAcceleratorPlugin. This is a 3D graphics support
> plugin that uses GL. It was written by Andreas Raab, a distinguished Squeak
> guru and expert in graphics and VM programming. Andreas is less active on the
> list that he once was, but I'm sure he will chime it and offer some guidance
> once in a while. For now though, just treat this as a non-trivial example of
> interfacing to GL with a plugin.
>
> Last but not least: Build a VM. This will be a minimal configuration with
> only a few plugins, but it is enough to get you started. If you are able to
> do this successfully, then you have everything you need in order to start
> making your own plugins.

>
>    world -> open... -> VMMaker
>    click the the "Help" button and spend a few minutes reading it.
>    click the "Entire" button to generate VM source code.
>    This will translate the Smalltalk VM and plugin source code into C source
>      files, which will be stored in the directory src along side your platforms
>      directory. The platforms directory should contain all of the sources that
>      you downloaded with Subversion, the the src directory will contain the generated sources from Smalltalk.
>
> Now open a terminal window. Compile your VM as follows:
>
>    $ mkdir build
>    $ cd build
>    $ ../platforms/unix/cmake/configure --src=../src --without-gl
>    $ make
>
> If you want to install your new VM, do a "make install".
>
> HTH,
> Dave
>
>

> thank you very much , I have stored your instructions as pdf and will take a look at the plugin tutorials again. Will try your instructions when my computer has wifi internet again. Will an image update erase my work ? is it safe ? I will first upload to squeaksource my work just to be sure.?
>
>
> ________________________________
>  From: David T. Lewis [via Smalltalk] <[hidden email]>
> To: kilon <[hidden email]>
> Sent: Sunday, 19 August 2012, 0:53
> Subject: How to build plugins and VMs (was: Opengl and Squeak)
>  
>
> On Sat, Aug 18, 2012 at 08:19:34AM +0100, dimitris chloupis wrote:
>
> Hi Dimitris,
>
> Skip to the bottom for the important part, how to build plugins.
>
> But first I will try to answer your questions.
>
> > Why coders prefer FFIs ??
> >
>
> Some people prefer FFIs because it allows the interface to be done
> without using compilers or building VMs, and because it is not necessary
> to distribute a compiled plugin to provide the platform interface.
>
> Some people may prefer using an FFI because they think it will save
> time. They are usually wrong. Unfortunately, by the time they figure
> this out, they will have wasted a lot of time trying to do things the
> "easy way", and never bothered to invest a few hours to learn how to
> do it more reliably with a plugin.
>
> > For example I am a python coder, ctypes which is the FFI cpython comes with has seen an explosion the last years . The most suprising is the conversion of pyOpeng from C extenstion to ctypes libraries even though that has slow down the library 2-3x times. The reason behind that move is not hard to guess. Much easier to maintain. FFIs remove one importan element from the equation and pretty much why people avoid using C in the first place. Compiling and building. Thus making FFIs ideals for the fast changing libraries , be able to change things on the fly and not have to suffer the slow downs of the C compiler.?
> >
>
> Yes, an FFI is very adaptable because all changes can be done in the image,
> and that is a good thing. However, relying on the compiler is only a
> problem if you are waiting for someone *else* to compile it for you.
> If you are willing to learn to do it for yourself, it is actually very
> fast and easy to make updates. And if you do most of your work in Smalltalk
> (aka "slang"), you will manage it with the same version control and tools
> that you use for all the rest of your Smalltalk work.
>
> You will find that you have far better support for debugging and profiling
> when you use a plugin, because you can use the platform debuggers and other
> tools directly. Also (and this is a really big thing in practice), you
> have the benefits of strong type checking provided by the C compiler when
> you build the interface as a plugin rather than directing your calls through
> an FFI interface.
>
> > I have taken a look at VM plugins, glanced through some tutorials, if I am not mistaken Slang is used to produce C code that then is compiled in a form that can be loaded by the VM is a primitive. The like an FFI call , you just use the primitive to execute the action.?
> >
>
> Yes, that's right.
>
> > I am definetly interested , and if you have any link I am more than welcome them, my only hesitation is buidling C files . I am the type of coder that likes to moves one line of code (or several ) per time and always make sure by testing that I dont code garbage. One of the reason I decided to convert from python to squeak was because I felt that it was easier to "live code" in this enviroment. I fear that a VM plugin might cut short this experience. Please correct me If I am mistaken.?
> >
>
> See below for instructions that should help get you started. My explanation
> assumes you are using unix/Linux, so please let me know if you are on
> Windows or Mac or something else.
>
> > Saying that I have installed with ease CroquetGL and the opengl example seems to run fine, (exampletex fails but that is to be expected , have not tried the fix yet).?
> >
> > If VM plugins are more stable, reliable and what the squeak community prefers I have no issues going down that route.?
> >
>
> You will probably not get a consensus from the community. I am giving you
> an opinion based on my own personal experience.
>
> OK, with that out of the way, here is what you should do:
>
> Allow about two hours to work through these instructions for the first time.
> If you are using Linux or Unix, you can follow the steps exactly. If you
> use another platform, just do the things you can, and you will still be able
> to get an idea of how things works. Here are the steps to follow:
>
> Prepare tools. On Linux, install dev tools, libraries of interest, and Subversion.
>
> Get a copy of the platform sources. Do this in the same directory in which
> you will be running your Squeak image. On Linux:
>
> ? $ svn co http://squeakvm.org/svn/squeak/trunk/platforms
>
> Any recent Squeak image will work for building VMs, but I like to work with
> an updated trunk image, like this:
>
> ? world -> open... -> morphic project
> ? (enter the project)
> ? [menu bar] Tools -> Preferences
> ? (select category Monticello. change Update URL from http://source.squeak.org/squeak43?to http://source.squeak.org/trunk.
> ? ? accept the change (<ctl> s). click save button)
> ? world -> help... -> update code from server
> ? (wait for update process to complete, then save your image)
>
> Install VMMaker. This is the trunk version for an interpreter VM. Do it this way
> to get started so that you will be able to see your generated C code in a browser.
>
> ? world -> open... Squeak Map Catalog
> ? in the Squeak Map browser, click Update
> ? select package VMMaker, version "head"
> ? click Install
> ? (wait for installation to complete)
>
> ? In a workspace, evaluate "VMMaker initialize". This will activate the Slang browsing tools.
> ? (note: in the future, you can evaluate "VMMaker updateFromServer" to keep your VMMaker up to date)
>
> Now have a look at some plugins.
>
> Open a browser on UnixOSProcessPlugin>>primitiveGetUid. This is a simple
> primitive call that links to the getuid() function in the C runtime library,
> and answers your uid when the primitive is called. This is how the primitive
> looks in Smalltalk. There is no C support code required, just the Smalltalk
> code that you see here.
>
> While looking at the primitiveGetUid method, click the "source" button on
> the browser, then select either "translate inlined C". You will now see
> the C code for the primitive.
>
> Explore a few more primitives and other methods, and have a look at other
> plugins, looking at both the Smalltalk source code and the generated C code.
>
> Now point your browser at B3DAcceleratorPlugin. This is a 3D graphics support
> plugin that uses GL. It was written by Andreas Raab, a distinguished Squeak
> guru and expert in graphics and VM programming. Andreas is less active on the
> list that he once was, but I'm sure he will chime it and offer some guidance
> once in a while. For now though, just treat this as a non-trivial example of
> interfacing to GL with a plugin.
>
> Last but not least: Build a VM. This will be a minimal configuration with
> only a few plugins, but it is enough to get you started. If you are able to
> do this successfully, then you have everything you need in order to start
> making your own plugins.
>
> ? world -> open... -> VMMaker
> ? click the the "Help" button and spend a few minutes reading it.
> ? click the "Entire" button to generate VM source code.
> ? This will translate the Smalltalk VM and plugin source code into C source
> ? ? files, which will be stored in the directory src along side your platforms
> ? ? directory. The platforms directory should contain all of the sources that
> ? ? you downloaded with Subversion, the the src directory will contain the generated sources from Smalltalk.
>
> Now open a terminal window. Compile your VM as follows:
>
> ? $ mkdir build
> ? $ cd build
> ? $ ../platforms/unix/cmake/configure --src=../src --without-gl
> ? $ make
>
> If you want to install your new VM, do a "make install".
>
> HTH,
> Dave
>
>
>
>
> ________________________________
>  
> If you reply to this email, your message will be added to the discussion below:http://forum.world.st/Opengl-and-Squeak-tp4644265p4644557.html 
> To unsubscribe from Opengl and Squeak, click here.
> NAML
>

>
> Also last time I checked NBOpenGL was not available for all platforms. That
> was at least 6 months ago. I dont have a problem using pharo with some
> squeak libraries. The project I am making will be most likely a bridge
> between pharo and squeak. Since both projects have some very useful
> libraries .  I have also created a thread about this in pharo mailing list
> some time ago, I want to reimplement morphic in opengl and do my own
> explorations too. I think I will give another go to NBOpenGL and see how it
> will go.
>

> ________________________________
> From: Igor Stasenko [via Smalltalk]
> <[hidden email]>
> To: kilon <[hidden email]>
> Sent: Saturday, 18 August 2012, 20:31
> Subject: Re: Opengl and Squeak
>
> On 17 August 2012 08:51, dimitris chloupis <[hidden email]> wrote:
>> Well if FFI works okish in squeak I dont have a need for nativeboost,
>> since
>> I prefer to code in smalltalk than assembly.
>>
> You don't have to learn assembly to use OpenGL with Nativeboost.
> Also, replying to previous post, it supports all 3 major platforms -
> mac, unix and windows.
>
> As for making NB working on Squeak, except from VM there's only one
> significant change
> made in Pharo but not in Squeak (afaik) is to improve the debugger
> support for custom primitives.
>
>> I decided to continue my project 'Ephestos' is squeak, since Blender
>> python
>> has been a complete failure, the opengl implementation is buggy , still
>> stuck to version 1.1 and it consumes CPU cycles like crazy (simple hand
>> morph system  consume 50% of my dual core) so fingers crossed it will
>> works
>> with squeak. I dont care for fancy features like nativevboost if its
>> buggy,
>> non cross platform and slow.
>>
>> Seems I am not getting replies from other than you lawson , I assume
>> something is wrong with my squeak-dev subscription.
>>
>> Anyway, will test FFI from CroquetGL and hopefully it will work for me
>> too.Thanks for the help.
>> ________________________________
>> From: Lawson English <[hidden email]>
>> To: [hidden email]
>> Sent: Thursday, 16 August 2012, 23:07
>>
>> Subject: Re: [squeak-dev] Opengl and Squeak
>>
>> thanks Hans-Martin. I'll update my videos with that bit of info too.
>>
>> I have been playing quite a bit with NativeBoost lately and it offers some
>> very nice features that anyone wanting to make a game or other
>> realtime-ish
>> application will find beneficial, including the ability to create a
>> "cascade" of foreign file calls within a single method, or even program a
>> bit of custom x86 assembler. I don't know what will be involved to port it
>> to Squeak, but Igor's talk suggests that the only "special" bit is already
>> present in the VM, which should work with either Pharo or Squeak. The rest
>> is just glue code at the Smalltalk level, which means that it is perfectly
>> doable to get it working on Squeak, in theory at least.
>>
>> Native boost also offers a way of passing an arbitrary  ByteArray to an
>> external function as though it were a normal pointer to a bit of malloc-ed
>> memory, which can be VERY useful with certain libraries, that and the
>> ability to actually malloc memory for a ByteArray from the OS level heap,
>> opens up all sorts of possibilities like having an external lib render
>> directly into a BitMap object asynchronously from its own OS level thread
>> so
>> that each update can show the library's progress in a morph without any
>> further coding.
>>
>> I'm actually working on a simple MandelBrot Set generator lib in C to demo
>> this.
>>
>> L.
>>
>>
>>
>> On 8/16/12 12:38 PM, Hans-Martin Mosner wrote:
>>> The Squeak OpenGL bindings are on squeaksource.com. Here is an older mail
>>> exchange describing the installation procedure:
>>> http://forum.world.st/OpenGL-in-4-1-or-later-td3794639.html I have just
>>> tried it in a 4.3 image, and after fixing three small glitches it worked:
>>> -
>>> somehow the method OGLUnix>>#openGLLibraryName has an illegal character
>>> at
>>> the end (it's probably being handled as whitespace in other Squeak/Pharo
>>> images) - the method Point>>#area does not exist. I implemented it as
>>> returning x*y, which works. - the method printShowingMaxDecimalPlaces:
>>> does
>>> not exist. I used printString instead. That should get you started.
>>> Cheers,
>>> Hans-Martin
>>
>>
>> -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk
>> for the (almost) complete and compleate beginner).
>> https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://forum.world.st/Opengl-and-Squeak-tp4644265p4644549.html
> To unsubscribe from Opengl and Squeak, click here.
> NAML
>
>
>
>
>

> On Sat, Aug 18, 2012 at 08:19:34AM +0100, dimitris chloupis wrote:
>
> Hi Dimitris,
>
> Skip to the bottom for the important part, how to build plugins.
>
> But first I will try to answer your questions.
>
>> Why coders prefer FFIs ??
>>
> Some people prefer FFIs because it allows the interface to be done
> without using compilers or building VMs, and because it is not necessary
> to distribute a compiled plugin to provide the platform interface.
>
> Some people may prefer using an FFI because they think it will save
> time. They are usually wrong. Unfortunately, by the time they figure
> this out, they will have wasted a lot of time trying to do things the
> "easy way", and never bothered to invest a few hours to learn how to
> do it more reliably with a plugin.
>
>> For example I am a python coder, ctypes which is the FFI cpython comes with has seen an explosion the last years . The most suprising is the conversion of pyOpeng from C extenstion to ctypes libraries even though that has slow down the library 2-3x times. The reason behind that move is not hard to guess. Much easier to maintain. FFIs remove one importan element from the equation and pretty much why people avoid using C in the first place. Compiling and building. Thus making FFIs ideals for the fast changing libraries , be able to change things on the fly and not have to suffer the slow downs of the C compiler.?
>>
> Yes, an FFI is very adaptable because all changes can be done in the image,
> and that is a good thing. However, relying on the compiler is only a
> problem if you are waiting for someone *else* to compile it for you.
> If you are willing to learn to do it for yourself, it is actually very
> fast and easy to make updates. And if you do most of your work in Smalltalk
> (aka "slang"), you will manage it with the same version control and tools
> that you use for all the rest of your Smalltalk work.
>
> You will find that you have far better support for debugging and profiling
> when you use a plugin, because you can use the platform debuggers and other
> tools directly. Also (and this is a really big thing in practice), you
> have the benefits of strong type checking provided by the C compiler when
> you build the interface as a plugin rather than directing your calls through
> an FFI interface.
>
>> I have taken a look at VM plugins, glanced through some tutorials, if I am not mistaken Slang is used to produce C code that then is compiled in a form that can be loaded by the VM is a primitive. The like an FFI call , you just use the primitive to execute the action.?
>>
> Yes, that's right.
>
>> I am definetly interested , and if you have any link I am more than welcome them, my only hesitation is buidling C files . I am the type of coder that likes to moves one line of code (or several ) per time and always make sure by testing that I dont code garbage. One of the reason I decided to convert from python to squeak was because I felt that it was easier to "live code" in this enviroment. I fear that a VM plugin might cut short this experience. Please correct me If I am mistaken.?
>>
> See below for instructions that should help get you started. My explanation
> assumes you are using unix/Linux, so please let me know if you are on
> Windows or Mac or something else.
>
>> Saying that I have installed with ease CroquetGL and the opengl example seems to run fine, (exampletex fails but that is to be expected , have not tried the fix yet).?
>>
>> If VM plugins are more stable, reliable and what the squeak community prefers I have no issues going down that route.?
>>
> You will probably not get a consensus from the community. I am giving you
> an opinion based on my own personal experience.
>
> OK, with that out of the way, here is what you should do:
>
> Allow about two hours to work through these instructions for the first time.
> If you are using Linux or Unix, you can follow the steps exactly. If you
> use another platform, just do the things you can, and you will still be able
> to get an idea of how things works. Here are the steps to follow:
>
> Prepare tools. On Linux, install dev tools, libraries of interest, and Subversion.
>
> Get a copy of the platform sources. Do this in the same directory in which
> you will be running your Squeak image. On Linux:
>
>    $ svn co http://squeakvm.org/svn/squeak/trunk/platforms
>
> Any recent Squeak image will work for building VMs, but I like to work with
> an updated trunk image, like this:
>
>    world -> open... -> morphic project
>    (enter the project)
>    [menu bar] Tools -> Preferences
>    (select category Monticello. change Update URL from http://source.squeak.org/squeak43 to http://source.squeak.org/trunk.
>      accept the change (<ctl> s). click save button)
>    world -> help... -> update code from server
>    (wait for update process to complete, then save your image)
>
> Install VMMaker. This is the trunk version for an interpreter VM. Do it this way
> to get started so that you will be able to see your generated C code in a browser.
>
>    world -> open... Squeak Map Catalog
>    in the Squeak Map browser, click Update
>    select package VMMaker, version "head"
>    click Install
>    (wait for installation to complete)
>
>    In a workspace, evaluate "VMMaker initialize". This will activate the Slang browsing tools.
>    (note: in the future, you can evaluate "VMMaker updateFromServer" to keep your VMMaker up to date)
>
> Now have a look at some plugins.
>
> Open a browser on UnixOSProcessPlugin>>primitiveGetUid. This is a simple
> primitive call that links to the getuid() function in the C runtime library,
> and answers your uid when the primitive is called. This is how the primitive
> looks in Smalltalk. There is no C support code required, just the Smalltalk
> code that you see here.
>
> While looking at the primitiveGetUid method, click the "source" button on
> the browser, then select either "translate inlined C". You will now see
> the C code for the primitive.
>
> Explore a few more primitives and other methods, and have a look at other
> plugins, looking at both the Smalltalk source code and the generated C code.
>
> Now point your browser at B3DAcceleratorPlugin. This is a 3D graphics support
> plugin that uses GL. It was written by Andreas Raab, a distinguished Squeak
> guru and expert in graphics and VM programming. Andreas is less active on the
> list that he once was, but I'm sure he will chime it and offer some guidance
> once in a while. For now though, just treat this as a non-trivial example of
> interfacing to GL with a plugin.
>
> Last but not least: Build a VM. This will be a minimal configuration with
> only a few plugins, but it is enough to get you started. If you are able to
> do this successfully, then you have everything you need in order to start
> making your own plugins.
>
>    world -> open... -> VMMaker
>    click the the "Help" button and spend a few minutes reading it.
>    click the "Entire" button to generate VM source code.
>    This will translate the Smalltalk VM and plugin source code into C source
>      files, which will be stored in the directory src along side your platforms
>      directory. The platforms directory should contain all of the sources that
>      you downloaded with Subversion, the the src directory will contain the generated sources from Smalltalk.
>
> Now open a terminal window. Compile your VM as follows:
>
>    $ mkdir build
>    $ cd build
>    $ ../platforms/unix/cmake/configure --src=../src --without-gl
>    $ make
>
> If you want to install your new VM, do a "make install".
>
> HTH,
> Dave
>
>
>

> On 12-08-18 5:53 PM, David T. Lewis wrote:
>>
>> You will find that you have far better support for debugging and profiling
>> when you use a plugin, because you can use the platform debuggers and
>> other
>> tools directly. Also (and this is a really big thing in practice), you
>> have the benefits of strong type checking provided by the C compiler when
>> you build the interface as a plugin rather than directing your calls
>> through
>> an FFI interface.
>>