I was wondering why I need to install FFI and why it is not included by default. Any programming language I have used included at least a single FFI with it in its implementations or at least something similar.
Is there a specfic reason why its not included ? |
Many applications do not need FFI, so it including would add
unnecessary (in many cases) bits to the footprint. FFI is a one-click install from SqueakMap, which can be accessed programmatically via the Installer class, which is included with Squeak. HTH. On Thu, Aug 16, 2012 at 12:16 PM, kilon <[hidden email]> wrote: > I was wondering why I need to install FFI and why it is not included by > default. Any programming language I have used included at least a single FFI > with it in its implementations or at least something similar. > > Is there a specfic reason why its not included ? > > > > -- > View this message in context: http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > |
On 16.08.2012, at 22:28, Chris Muller <[hidden email]> wrote:
> Many applications do not need FFI, so it including would add > unnecessary (in many cases) bits to the footprint. > > FFI is a one-click install from SqueakMap, which can be accessed > programmatically via the Installer class, which is included with > Squeak. > > HTH. Right. Also, if we included it by default, people might think it is okay to use for providing basic functions. If FFI calls started to creep into the basic image we would lose the big advantage of platform independence. - Bert - > > On Thu, Aug 16, 2012 at 12:16 PM, kilon <[hidden email]> wrote: >> I was wondering why I need to install FFI and why it is not included by >> default. Any programming language I have used included at least a single FFI >> with it in its implementations or at least something similar. >> >> Is there a specfic reason why its not included ? >> >> >> >> -- >> View this message in context: http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264.html >> Sent from the Squeak - Dev mailing list archive at Nabble.com. >> > |
On 8/17/12 11:21 AM, Bert Freudenberg wrote:
> On 16.08.2012, at 22:28, Chris Muller <[hidden email]> wrote: > >> Many applications do not need FFI, so it including would add >> unnecessary (in many cases) bits to the footprint. >> >> FFI is a one-click install from SqueakMap, which can be accessed >> programmatically via the Installer class, which is included with >> Squeak. >> >> HTH. > Right. Also, if we included it by default, people might think it is okay to use for providing basic functions. If FFI calls started to creep into the basic image we would lose the big advantage of platform independence. > > - Bert - > > Which is a huge downside to the current implementation of NativeBoost, although, in theory, you could create a version that would compile to C via slang rather than using Igor's x86 assembler syntax. L -- 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 17/08/12 2:46 PM, Lawson English wrote:
> > Which is a huge downside to the current implementation of NativeBoost, > although, in theory, you could create a version that would compile to C > via slang rather than using Igor's x86 assembler syntax. But it's called *Native*Boost. Are you suggesting non-native boost? Wouldn't that be Cog/JIT? |
On 8/17/12 1:21 PM, Yanni Chiu wrote:
> On 17/08/12 2:46 PM, Lawson English wrote: >> >> Which is a huge downside to the current implementation of NativeBoost, >> although, in theory, you could create a version that would compile to C >> via slang rather than using Igor's x86 assembler syntax. > > But it's called *Native*Boost. Are you suggesting non-native boost? > Wouldn't that be Cog/JIT? > > > > The difference is that you have full control of what is going on. Cog has to make *some* assumptions, including the one that it can release memory for the JIT-ed compiled method if it hasn't been called lately. But what if the speed of that method, no matter how seldom it is called, is essential to the proper functioning of your application? Also, a more common situation is simply that the overhead of boxing and unboxing of floats is going to make things unusable in a practical situation. For example, the speed of the inner loop of a mandelbrot set generator is many dozens of times slower using Cog than the same loop implemented in C as an external library. Since the "dwell table" of a 1000x1000 pixel image of the entire set can be generated in 1/10 of a second using the naive M-set code written in C, you don't need to worry too much about the VM stalling if that loop were implemented using NativeBoost. Of course, for any arbitrarily "deep" render of the set, you still need to work with the set via an external library running in its own thread or process because such images can take days or even years to fully render. A more interesting usecase would be implementing robust raytracing or physics for a Cobalt-like/Croquet-like application or even a normal standalone 3D game. What I am suggesting is that a simple slang to C compiler could be implemented in Squeak which injects native bytecode into a CompiledMethod object in the same way that NativeBoost does, which would give you almost as much control as the NativeBoost assembler, and which would work even if the compiler hadn't yet been implemented in a specific platform. It could be added later as a plugin. In theory, such a beast could be implemented in a few days or weeks, even by someone like me, by simply passing the properly pre-processed Slang code as arguments to the gcc compiler and then injecting the bytecodes in the same way that NativeBoost does. This, of course, would be horrible for anything but a proof of concept but I think Igor says such a thing has already been done by some students somewhere. L -- 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 |
In reply to this post by Bert Freudenberg
First thank you all for your answers. Suffice to say I have installed FFI from source.squeak , Win32 refuses to install for me(I am on MacoOSX if that is of any importance [Lion]). The argument that "we dont include FFI because we dont want to encourage people to use it instead of smalltalk" is something that does not convince me. FFIs exist included in implementations of all languages I have programmed with Python , Java, Common lisp (ccl) , Free Pascal etc . I was a python developer so far, ctypes which is the interface of python itself is used exactly because ( though its way slower than writing C extensions ) it allows coders to stick with python and make code easier to port across platforms. In my
experience coders dont use FFIs just for the fun for it, because they are not fun , they can be a pain in the hat. Also a coder preferring FFI from the comfort of the amazing smalltalk debugger is something I have a very hard time imagining. People use FFIs because well , they want to acess a functionality that the existing libraries just do not offer and that functionality exist on OS level anyway that will require some mangling with C. So no I dont think FFI will ever reduce the portability of squeak or that FFI libraries will start to pop up like mushrooms. Its not such an issue for me because : a) I can provide an image that will have FFI included b) unlike python squeak distribution system (monitcello) not only does not suck but seems to work quite well. " Many applications do not need FFI" that could be said for a lot of smalltalk libraries already included with squeak. For example I have not seen many apps in squeak source make use of etoys ( I love etoys by the way and one of the reason I prefer Squeak from Pharo and is potentially necessary for a project I am making). I dont think that is a good excuse as well. Libraries dont need to be super popular to be included in a language implementations they are included to offer a more "complete" experience to the code as long they provide "basic" functionality and not something that is highly specialised. In any case I asked the question not because I want to force the inclusion of FFIs but because its the first time in last decade or so that I use a language implementation that does not come included with an FFI and tham
made me curious about the reason behind this. In any case I love what you have done with Squeak, I really enjoy using it and even though it lacks documentation in several areas it really is easy to understand what is going on because of the overall architecture and the elegance of tools like inspector, and browser. Let me state all the above is my personal opinion and not an effort to play it smart or being rude, just geniune curiosity. From: Bert Freudenberg <[hidden email]> To: "[hidden email]" <[hidden email]>; The general-purpose Squeak developers list <[hidden email]> Cc: The general-purpose Squeak developers list <[hidden email]> Sent: Friday, 17 August 2012, 21:21 Subject: Re: [squeak-dev] Why FFI is not included with latest squeak ? On 16.08.2012, at 22:28, Chris Muller <[hidden email]> wrote: > Many applications do not need FFI, so it including would add > unnecessary (in many cases) bits to the footprint. > > FFI is a one-click install from SqueakMap, which can be accessed > programmatically via the Installer class, which is included with > Squeak. > > HTH. Right. Also, if we included it by default, people might think it is okay to use for providing basic functions. If FFI calls started to creep into the basic image we would lose the big advantage of platform independence. - Bert - > > On Thu, Aug 16, 2012 at 12:16 PM, kilon <[hidden email]> wrote: >> I was wondering why I need to install FFI and why it is not included by >> default. Any programming language I have used included at least a single FFI >> with it in its implementations or at least something similar. >> >> Is there a specfic reason why its not included ? >> >> >> >> -- >> View this message in context: http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264.html >> Sent from the Squeak - Dev mailing list archive at Nabble.com. >> > |
I am using squeak, I am learning it and I am loving it. I know its not perfect, I know it has it faults , but I feel I finally found an enviroment that I can do what I always want "live coding" As you can imagine as a begineer I spent a lot of time in system browser and I am suprised by the lack of documentation to some basic classes. Now I am probably the last person to qualify as a person to document those classes since my experience is very limited with Squeak and smalltalk. But I feel that some documentation even if its a partial one , is better than no documentation. And since I am already reading so much of the souce , why not save people's time and mine (I can foget easily the code I read and so a documentation string can help me remember) by adding
documentation strings to classes and their methods. The only things I dont know is how to make those documentations port back to squeak standard distribution. I assume would need some commit rights to the squeak source ? From: dimitris chloupis <[hidden email]> To: The general-purpose Squeak developers list <[hidden email]> Sent: Saturday, 18 August 2012, 10:09 Subject: Re: [squeak-dev] Why FFI is not included with latest squeak ? First thank you all for your answers. Suffice to say I have installed FFI from source.squeak , Win32 refuses to install for me(I am on MacoOSX if that is of any importance [Lion]). The argument that "we dont include FFI because we dont want to encourage people to use it instead of smalltalk" is something that does not convince me. FFIs exist included in implementations of all languages I have programmed with Python , Java, Common lisp (ccl) , Free Pascal etc . I was a python developer so far, ctypes which is the interface of python itself is used exactly because ( though its way slower than writing C extensions )
it allows coders to stick with python and make code easier to port across platforms. In my
experience coders dont use FFIs just for the fun for it, because they are not fun , they can be a pain in the hat. Also a coder preferring FFI from the comfort of the amazing smalltalk debugger is something I have a very hard time imagining. People use FFIs because well , they want to acess a functionality that the existing libraries just do not offer and that functionality exist on OS level anyway that will require some mangling with C. So no I dont think FFI will ever reduce the portability of squeak or that FFI libraries will start to pop up like mushrooms. Its not such an issue for me because : a) I can provide an image that will have FFI included b) unlike python squeak distribution system (monitcello) not only does not suck but seems to work quite well. " Many applications do not need FFI" that could be said for a lot of smalltalk libraries already included with squeak. For example I have not seen many apps in squeak source make use of etoys ( I love etoys by the way and one of the reason I prefer Squeak from Pharo and is potentially necessary for a project I am making). I dont think that is a good excuse as well. Libraries dont need to be super popular to be included in a language implementations they are included to offer a more "complete" experience to the code as long they provide "basic" functionality and not something that is highly specialised. In any case I asked the question not because I want to force the inclusion of FFIs but because its the first time in last decade or so that I use a language implementation that does not come included with an FFI and tham
made me curious about the reason behind this. In any case I love what you have done with Squeak, I really enjoy using it and even though it lacks documentation in several areas it really is easy to understand what is going on because of the overall architecture and the elegance of tools like inspector, and browser. Let me state all the above is my personal opinion and not an effort to play it smart or being rude, just geniune curiosity. From: Bert Freudenberg <[hidden email]> To: "[hidden email]" <[hidden email]>; The general-purpose Squeak developers list <[hidden email]> Cc: The general-purpose Squeak developers list <[hidden email]> Sent: Friday, 17 August 2012, 21:21 Subject: Re: [squeak-dev] Why FFI is not included with latest squeak ? On 16.08.2012, at 22:28, Chris Muller <[hidden email]> wrote: > Many applications do not need FFI, so it including would add > unnecessary (in many cases) bits to the footprint. > > FFI is a one-click install from SqueakMap, which can be accessed > programmatically via the Installer class, which is included with > Squeak. > > HTH. Right. Also, if we included it by default, people might think it is okay to use for providing basic functions. If FFI calls started to creep into the basic image we would lose the big advantage of platform independence. - Bert - > > On Thu, Aug 16, 2012 at 12:16 PM, kilon <[hidden email]> wrote: >> I was wondering why I need to install FFI and why it is not included by >> default. Any programming language I have used included at least a single FFI >> with it in its implementations or at least something similar. >> >> Is there a specfic reason why its not included ? >> >> >> >> -- >> View this message in context: http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264.html >> Sent from the Squeak - Dev mailing list archive at Nabble.com. >> > |
Sorry for the initial quotes I used one of my previous posts as a template and forgot to delete it. Of course my question still stands ;) From: dimitris chloupis <[hidden email]> To: The general-purpose Squeak developers list <[hidden email]> Sent: Saturday, 18 August 2012, 10:29 Subject: [squeak-dev] How may I contribute in documenting classes ? I am using squeak, I am learning it and I am loving it. I know its not perfect, I know it has it faults , but I feel I finally found an enviroment that I can do what I always want "live coding" As you can imagine as a begineer I spent a lot of time in system browser and I am suprised by the lack of documentation to some basic classes. Now I am probably the last person to qualify as a person to document those classes since my experience is very limited with Squeak and smalltalk. But I feel that some documentation even if its a partial one , is better than no documentation. And since I am already reading so much of the souce , why not save people's time and mine (I can foget easily the code I read and so a
documentation string can help me remember) by adding
documentation strings to classes and their methods. The only things I dont know is how to make those documentations port back to squeak standard distribution. I assume would need some commit rights to the squeak source ? |
In reply to this post by kilon
Squeak's development happens on http://source.squeak.org
You can just write comments for classes and commit these changes (changed packages) to the Inbox project, which is writable by anyone. I guess ideally you'd use a trunk image with the latest updates. Contributions from the Inbox can be then moved into the trunk by trunk developers (or not).
rado
On Sat, Aug 18, 2012 at 9:29 AM, dimitris chloupis <[hidden email]> wrote:
|
In reply to this post by kilon
On 18 August 2012 08:29, dimitris chloupis <[hidden email]> wrote:
> I am using squeak, I am learning it and I am loving it. I know its not > perfect, I know it has it faults , but I feel I finally found an enviroment > that I can do what I always want "live coding" > > As you can imagine as a begineer I spent a lot of time in system browser and > I am suprised by the lack of documentation to some basic classes. Now I am > probably the last person to qualify as a person to document those classes > since my experience is very limited with Squeak and smalltalk. But I feel > that some documentation even if its a partial one , is better than no > documentation. And since I am already reading so much of the souce , why not > save people's time and mine (I can foget easily the code I read and so a > documentation string can help me remember) by adding documentation strings > to classes and their methods. > > The only things I dont know is how to make those documentations port back to > squeak standard distribution. I assume would need some commit rights to the > squeak source ? I wholeheartedly agree that there are a whole pile of things in the base image desperately needing comments. Your commits will be most welcome! Add your class comments, and use Monticello to save your edited packages (as shown in the Monticello Browser) to the Inbox. I don't have an image close at hand, but you should have the Inbox as one of the repositories in the right hand pane of the Monticello Browser. (If it's not there, we ought to add it as part of the standard released image, so let me know.) If it's not there, right click the "trunk" repository, select "edit repository info" and copy that chunk of text. Cancel the dialog, and press the "+ Repository" button. Paste in the text, and change "trunk" to "inbox". Sometimes when you select the package you want to save you don't see the repository you want to push to in the right hand pane. I often find it easier to just save the package to my package-cache repository and, from the version browser that pops up, just Copy the version to whichever repo I want. Once it's in the Inbox, the core devs can have a look at the class comment, review it, ask you to change some things if necessary, and they'll take care of pushing the comments into the Trunk. frank > ________________________________ > From: dimitris chloupis <[hidden email]> > To: The general-purpose Squeak developers list > <[hidden email]> > Sent: Saturday, 18 August 2012, 10:09 > Subject: Re: [squeak-dev] Why FFI is not included with latest squeak ? > > First thank you all for your answers. Suffice to say I have installed FFI > from source.squeak , Win32 refuses to install for me(I am on MacoOSX if that > is of any importance [Lion]). > > The argument that "we dont include FFI because we dont want to encourage > people to use it instead of smalltalk" is something that does not convince > me. FFIs exist included in implementations of all languages I have > programmed with Python , Java, Common lisp (ccl) , Free Pascal etc . I was a > python developer so far, ctypes which is the interface of python itself is > used exactly because ( though its way slower than writing C extensions ) it > allows coders to stick with python and make code easier to port across > platforms. In my experience coders dont use FFIs just for the fun for it, > because they are not fun , they can be a pain in the hat. Also a coder > preferring FFI from the comfort of the amazing smalltalk debugger is > something I have a very hard time imagining. People use FFIs because well , > they want to acess a functionality that the existing libraries just do not > offer and that functionality exist on OS level anyway that will require some > mangling with C. So no I dont think FFI will ever reduce the portability of > squeak or that FFI libraries will start to pop up like mushrooms. > > Its not such an issue for me because : a) I can provide an image that will > have FFI included b) unlike python squeak distribution system (monitcello) > not only does not suck but seems to work quite well. > > " Many applications do not need FFI" that could be said for a lot of > smalltalk libraries already included with squeak. For example I have not > seen many apps in squeak source make use of etoys ( I love etoys by the way > and one of the reason I prefer Squeak from Pharo and is potentially > necessary for a project I am making). I dont think that is a good excuse as > well. Libraries dont need to be super popular to be included in a language > implementations they are included to offer a more "complete" experience to > the code as long they provide "basic" functionality and not something that > is highly specialised. > > In any case I asked the question not because I want to force the inclusion > of FFIs but because its the first time in last decade or so that I use a > language implementation that does not come included with an FFI and tham > made me curious about the reason behind this. In any case I love what you > have done with Squeak, I really enjoy using it and even though it lacks > documentation in several areas it really is easy to understand what is going > on because of the overall architecture and the elegance of tools like > inspector, and browser. Let me state all the above is my personal opinion > and not an effort to play it smart or being rude, just geniune curiosity. > > ________________________________ > From: Bert Freudenberg <[hidden email]> > To: "[hidden email]" <[hidden email]>; The general-purpose > Squeak developers list <[hidden email]> > Cc: The general-purpose Squeak developers list > <[hidden email]> > Sent: Friday, 17 August 2012, 21:21 > Subject: Re: [squeak-dev] Why FFI is not included with latest squeak ? > > On 16.08.2012, at 22:28, Chris Muller <[hidden email]> wrote: > >> Many applications do not need FFI, so it including would add >> unnecessary (in many cases) bits to the footprint. >> >> FFI is a one-click install from SqueakMap, which can be accessed >> programmatically via the Installer class, which is included with >> Squeak. >> >> HTH. > > Right. Also, if we included it by default, people might think it is okay to > use for providing basic functions. If FFI calls started to creep into the > basic image we would lose the big advantage of platform independence. > > - Bert - > >> >> On Thu, Aug 16, 2012 at 12:16 PM, kilon <[hidden email]> wrote: >>> I was wondering why I need to install FFI and why it is not included by >>> default. Any programming language I have used included at least a single >>> FFI >>> with it in its implementations or at least something similar. >>> >>> Is there a specfic reason why its not included ? >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264.html >>> Sent from the Squeak - Dev mailing list archive at Nabble.com. >>> >> > > > > > > > > > > |
thank you both for your replies, I registred in source.squeak and I am waiting for the approval. Regarding latest image , isn't squeak update (Squeak main memu) capable of updating to the latest ? I like the inbox idea, this way I can feel safe that I wont mess anything up. Is there a guideline of documenting classes (html link , article , pdf etc) ? From: Frank Shearar-3 [via Smalltalk] <[hidden email]> To: kilon <[hidden email]> Sent: Saturday, 18 August 2012, 14:00 Subject: Re: How may I contribute in documenting classes ?
On 18 August 2012 08:29, dimitris chloupis <[hidden email]> wrote:
> I am using squeak, I am learning it and I am loving it. I know its not > perfect, I know it has it faults , but I feel I finally found an enviroment > that I can do what I always want "live coding" > > As you can imagine as a begineer I spent a lot of time in system browser and > I am suprised by the lack of documentation to some basic classes. Now I am > probably the last person to qualify as a person to document those classes > since my experience is very limited with Squeak and smalltalk. But I feel > that some documentation even if its a partial one , is better than no > documentation. And since I am already reading so much of the souce , why not > save people's time and mine (I can foget easily the code I read and so a > documentation string can help me remember) by adding documentation strings > to classes and their methods. > > The only things I dont know is how to make those documentations port back to > squeak standard distribution. I assume would need some commit rights to the > squeak source ? base image desperately needing comments. Your commits will be most welcome! Add your class comments, and use Monticello to save your edited packages (as shown in the Monticello Browser) to the Inbox. I don't have an image close at hand, but you should have the Inbox as one of the repositories in the right hand pane of the Monticello Browser. (If it's not there, we ought to add it as part of the standard released image, so let me know.) If it's not there, right click the "trunk" repository, select "edit repository info" and copy that chunk of text. Cancel the dialog, and press the "+ Repository" button. Paste in the text, and change "trunk" to "inbox". Sometimes when you select the package you want to save you don't see the repository you want to push to in the right hand pane. I often find it easier to just save the package to my package-cache repository and, from the version browser that pops up, just Copy the version to whichever repo I want. Once it's in the Inbox, the core devs can have a look at the class comment, review it, ask you to change some things if necessary, and they'll take care of pushing the comments into the Trunk. frank > ________________________________ > From: dimitris chloupis <[hidden email]> > To: The general-purpose Squeak developers list > <[hidden email]> > Sent: Saturday, 18 August 2012, 10:09 > Subject: Re: [squeak-dev] Why FFI is not included with latest squeak ? > > First thank you all for your answers. Suffice to say I have installed FFI > from source.squeak , Win32 refuses to install for me(I am on MacoOSX if that > is of any importance [Lion]). > > The argument that "we dont include FFI because we dont want to encourage > people to use it instead of smalltalk" is something that does not convince > me. FFIs exist included in implementations of all languages I have > programmed with Python , Java, Common lisp (ccl) , Free Pascal etc . I was a > python developer so far, ctypes which is the interface of python itself is > used exactly because ( though its way slower than writing C extensions ) it > allows coders to stick with python and make code easier to port across > platforms. In my experience coders dont use FFIs just for the fun for it, > because they are not fun , they can be a pain in the hat. Also a coder > preferring FFI from the comfort of the amazing smalltalk debugger is > something I have a very hard time imagining. People use FFIs because well , > they want to acess a functionality that the existing libraries just do not > offer and that functionality exist on OS level anyway that will require some > mangling with C. So no I dont think FFI will ever reduce the portability of > squeak or that FFI libraries will start to pop up like mushrooms. > > Its not such an issue for me because : a) I can provide an image that will > have FFI included b) unlike python squeak distribution system (monitcello) > not only does not suck but seems to work quite well. > > " Many applications do not need FFI" that could be said for a lot of > smalltalk libraries already included with squeak. For example I have not > seen many apps in squeak source make use of etoys ( I love etoys by the way > and one of the reason I prefer Squeak from Pharo and is potentially > necessary for a project I am making). I dont think that is a good excuse as > well. Libraries dont need to be super popular to be included in a language > implementations they are included to offer a more "complete" experience to > the code as long they provide "basic" functionality and not something that > is highly specialised. > > In any case I asked the question not because I want to force the inclusion > of FFIs but because its the first time in last decade or so that I use a > language implementation that does not come included with an FFI and tham > made me curious about the reason behind this. In any case I love what you > have done with Squeak, I really enjoy using it and even though it lacks > documentation in several areas it really is easy to understand what is going > on because of the overall architecture and the elegance of tools like > inspector, and browser. Let me state all the above is my personal opinion > and not an effort to play it smart or being rude, just geniune curiosity. > > ________________________________ > From: Bert Freudenberg <[hidden email]> > To: "[hidden email]" <[hidden email]>; The general-purpose > Squeak developers list <[hidden email]> > Cc: The general-purpose Squeak developers list > <[hidden email]> > Sent: Friday, 17 August 2012, 21:21 > Subject: Re: [squeak-dev] Why FFI is not included with latest squeak ? > > On 16.08.2012, at 22:28, Chris Muller <[hidden email]> wrote: > >> Many applications do not need FFI, so it including would add >> unnecessary (in many cases) bits to the footprint. >> >> FFI is a one-click install from SqueakMap, which can be accessed >> programmatically via the Installer class, which is included with >> Squeak. >> >> HTH. > > Right. Also, if we included it by default, people might think it is okay to > use for providing basic functions. If FFI calls started to creep into the > basic image we would lose the big advantage of platform independence. > > - Bert - > >> >> On Thu, Aug 16, 2012 at 12:16 PM, kilon <[hidden email]> wrote: >>> I was wondering why I need to install FFI and why it is not included by >>> default. Any programming language I have used included at least a single >>> FFI >>> with it in its implementations or at least something similar. >>> >>> Is there a specfic reason why its not included ? >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264.html >>> Sent from the Squeak - Dev mailing list archive at Nabble.com. >>> >> > > > > > > > > > > If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264p4644525.html
|
Also note that there has been a huge effort in Pharo to document
classes. Maybe you can find low hanging fruits there... Nicolas 2012/8/18 dimitris chloupis <[hidden email]>: > thank you both for your replies, I registred in source.squeak and I am > waiting for the approval. Regarding latest image , isn't squeak update > (Squeak main memu) capable of updating to the latest ? I like the inbox > idea, this way I can feel safe that I wont mess anything up. > > Is there a guideline of documenting classes (html link , article , pdf etc) > ? > > ________________________________ > From: Frank Shearar-3 [via Smalltalk] > <[hidden email]> > To: kilon <[hidden email]> > Sent: Saturday, 18 August 2012, 14:00 > Subject: Re: How may I contribute in documenting classes ? > > On 18 August 2012 08:29, dimitris chloupis <[hidden email]> wrote: > >> I am using squeak, I am learning it and I am loving it. I know its not >> perfect, I know it has it faults , but I feel I finally found an >> enviroment >> that I can do what I always want "live coding" >> >> As you can imagine as a begineer I spent a lot of time in system browser >> and >> I am suprised by the lack of documentation to some basic classes. Now I am >> probably the last person to qualify as a person to document those classes >> since my experience is very limited with Squeak and smalltalk. But I feel >> that some documentation even if its a partial one , is better than no >> documentation. And since I am already reading so much of the souce , why >> not >> save people's time and mine (I can foget easily the code I read and so a >> documentation string can help me remember) by adding documentation strings >> to classes and their methods. >> >> The only things I dont know is how to make those documentations port back >> to >> squeak standard distribution. I assume would need some commit rights to >> the >> squeak source ? > > I wholeheartedly agree that there are a whole pile of things in the > base image desperately needing comments. Your commits will be most > welcome! > > Add your class comments, and use Monticello to save your edited > packages (as shown in the Monticello Browser) to the Inbox. > > I don't have an image close at hand, but you should have the Inbox as > one of the repositories in the right hand pane of the Monticello > Browser. (If it's not there, we ought to add it as part of the > standard released image, so let me know.) If it's not there, right > click the "trunk" repository, select "edit repository info" and copy > that chunk of text. Cancel the dialog, and press the "+ Repository" > button. Paste in the text, and change "trunk" to "inbox". > > Sometimes when you select the package you want to save you don't see > the repository you want to push to in the right hand pane. I often > find it easier to just save the package to my package-cache repository > and, from the version browser that pops up, just Copy the version to > whichever repo I want. > > Once it's in the Inbox, the core devs can have a look at the class > comment, review it, ask you to change some things if necessary, and > they'll take care of pushing the comments into the Trunk. > > frank > >> ________________________________ >> From: dimitris chloupis <[hidden email]> >> To: The general-purpose Squeak developers list >> <[hidden email]> >> Sent: Saturday, 18 August 2012, 10:09 >> Subject: Re: [squeak-dev] Why FFI is not included with latest squeak ? >> >> First thank you all for your answers. Suffice to say I have installed FFI >> from source.squeak , Win32 refuses to install for me(I am on MacoOSX if >> that >> is of any importance [Lion]). >> >> The argument that "we dont include FFI because we dont want to encourage >> people to use it instead of smalltalk" is something that does not convince >> me. FFIs exist included in implementations of all languages I have >> programmed with Python , Java, Common lisp (ccl) , Free Pascal etc . I was >> a >> python developer so far, ctypes which is the interface of python itself is >> used exactly because ( though its way slower than writing C extensions ) >> it >> allows coders to stick with python and make code easier to port across >> platforms. In my experience coders dont use FFIs just for the fun for it, >> because they are not fun , they can be a pain in the hat. Also a coder >> preferring FFI from the comfort of the amazing smalltalk debugger is >> something I have a very hard time imagining. People use FFIs because well >> , >> they want to acess a functionality that the existing libraries just do not >> offer and that functionality exist on OS level anyway that will require >> some >> mangling with C. So no I dont think FFI will ever reduce the portability >> of >> squeak or that FFI libraries will start to pop up like mushrooms. >> >> Its not such an issue for me because : a) I can provide an image that will >> have FFI included b) unlike python squeak distribution system (monitcello) >> not only does not suck but seems to work quite well. >> >> " Many applications do not need FFI" that could be said for a lot of >> smalltalk libraries already included with squeak. For example I have not >> seen many apps in squeak source make use of etoys ( I love etoys by the >> way >> and one of the reason I prefer Squeak from Pharo and is potentially >> necessary for a project I am making). I dont think that is a good excuse >> as >> well. Libraries dont need to be super popular to be included in a language >> implementations they are included to offer a more "complete" experience to >> the code as long they provide "basic" functionality and not something that >> is highly specialised. >> >> In any case I asked the question not because I want to force the inclusion >> of FFIs but because its the first time in last decade or so that I use a >> language implementation that does not come included with an FFI and tham >> made me curious about the reason behind this. In any case I love what you >> have done with Squeak, I really enjoy using it and even though it lacks >> documentation in several areas it really is easy to understand what is >> going >> on because of the overall architecture and the elegance of tools like >> inspector, and browser. Let me state all the above is my personal opinion >> and not an effort to play it smart or being rude, just geniune curiosity. >> >> ________________________________ >> From: Bert Freudenberg <[hidden email]> >> To: "[hidden email]" <[hidden email]>; The general-purpose >> Squeak developers list <[hidden email]> >> Cc: The general-purpose Squeak developers list >> <[hidden email]> >> Sent: Friday, 17 August 2012, 21:21 >> Subject: Re: [squeak-dev] Why FFI is not included with latest squeak ? >> >> On 16.08.2012, at 22:28, Chris Muller <[hidden email]> wrote: >> >>> Many applications do not need FFI, so it including would add >>> unnecessary (in many cases) bits to the footprint. >>> >>> FFI is a one-click install from SqueakMap, which can be accessed >>> programmatically via the Installer class, which is included with >>> Squeak. >>> >>> HTH. >> >> Right. Also, if we included it by default, people might think it is okay >> to >> use for providing basic functions. If FFI calls started to creep into the >> basic image we would lose the big advantage of platform independence. >> >> - Bert - >> >>> >>> On Thu, Aug 16, 2012 at 12:16 PM, kilon <[hidden email]> wrote: >>>> I was wondering why I need to install FFI and why it is not included by >>>> default. Any programming language I have used included at least a single >>>> FFI >>>> with it in its implementations or at least something similar. >>>> >>>> Is there a specfic reason why its not included ? >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> >>>> http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264.html >>>> Sent from the Squeak - Dev mailing list archive at Nabble.com. >>>> >>> >> >> >> >> >> >> >> >> >> >> > > > > ________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264p4644525.html > To unsubscribe from Why FFI is not included with latest squeak ?, click > here. > NAML > > > > > |
In reply to this post by kilon
> " Many applications do not need FFI" that could be said for a lot of
> smalltalk libraries already included with squeak. For example I have not > seen many apps in squeak source make use of etoys ( I love etoys by the way > and one of the reason I prefer Squeak from Pharo and is potentially > necessary for a project I am making). I dont think that is a good excuse as > well... We want to remove Etoys from the base image as well. > In any case I asked the question not because I want to force the inclusion > of FFIs but because its the first time in last decade or so that I use a > language implementation that does not come included with an FFI and tham We've tried to make installation of FFI as painless as possible. It doesn't seem so bad to just have to click "install". Maybe the other languages should follow this paradigm instead of including it... |
I thought e-toys was the main reason between the chasm between pharo and squeak, does that mean there is an intetion to reunite the two projects ? I am curious where squeak and pharo are going and I am worried how easy it will be for me to use libraries from both projects. Nope I would not want to remove ctypes from python, its inclusion makes it possible to run python applications that use ctypes with zero installation in OS that come with python included which is both Macos and Linux. That means that out of the python can use any native library. Opengl is a big example. Add to that that in macos Apple has implemented pyobjc which takes FFI a step further that makes it possible to use any pyobjc library and even pyobjc libraries to use python.And that in my book is a clear win .
Not only to include an FFI but also an extra layer that further automates interfacing with native libraries as if they are libraries made for that particular language. I see Squeak FFI tries to do something similar. Well installing FFI win32 on Macos for me at least has not been painless. It fails, I promise to reply back with the exact error. Also is there a "install" button, because I really missed it. I am on vacations and I have to download the files in another computer and install them in a diffirent computer. Because my macbook air has no ethernet port and the internet pc modem has no wifi.But that is not an issue as soon as I return back home. From: Chris Muller-3 [via Smalltalk] <[hidden email]> To: kilon <[hidden email]> Sent: Saturday, 18 August 2012, 20:02 Subject: Re: Why FFI is not included with latest squeak ?
> " Many applications do not need FFI" that could be said for a lot of
> smalltalk libraries already included with squeak. For example I have not > seen many apps in squeak source make use of etoys ( I love etoys by the way > and one of the reason I prefer Squeak from Pharo and is potentially > necessary for a project I am making). I dont think that is a good excuse as > well... We want to remove Etoys from the base image as well. > In any case I asked the question not because I want to force the inclusion > of FFIs but because its the first time in last decade or so that I use a > language implementation that does not come included with an FFI and tham We've tried to make installation of FFI as painless as possible. It doesn't seem so bad to just have to click "install". Maybe the other languages should follow this paradigm instead of including it... If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264p4644547.html
|
No, Etoys is not the main reason for the Squeak/Pharo split. There are quite a few Pharoers who like Etoys, but pretty much nobody likes its implementation, with the original design barely visible under all the hacks accumulated over the years. One difference between Pharo and Squeak is that we Squeakers want to make Etoys unloadable but keep it working, whereas in Pharo it was just removed. One of Pharo's main goals is getting a clean base system quickly, even if that means breaking lots of things that used too work. In Squeak we value backwards compatibility higher, even if that means cleaning the system takes longer. - Bert -
|
Bert Freudenberg wrote on Sun, 19 Aug 2012 01:11:11 +0300
> No, Etoys is not the main reason for the Squeak/Pharo split. Indeed, that is a common misconception. Cuis doesn't include Etoys either, but nobody would think that this was the motivation for its creation, right? > There are quite a few Pharoers who like Etoys, but pretty much nobody likes > its implementation, with the original design barely visible under all the hacks > accumulated over the years. This is particularly true of the people who created Etoys in the first place, who have ever since been working on its replacement (see the project list at VPRI). Unfortunately the world of education moves very slowly and what was meant as a quick and short lived experiment is still getting traction with new students and teachers over a decade later. And while I would love a much better Etoys, I miss it very much when using the systems that have dumped it. If you use Squeak as a programming language then it doesn't matter, but when Squeak is a system you use then not having Etoys feels very much like using Unix with C but not with any shell. > One difference between Pharo and Squeak is that we Squeakers want to make > Etoys unloadable but keep it working, whereas in Pharo it was just removed. > One of Pharo's main goals is getting a clean base system quickly, even if that > means breaking lots of things that used too work. In Squeak we value backwards > compatibility higher, even if that means cleaning the system takes longer. Just a little historical perspective for those who were not around in the old days - the Etoys used in schools forked from Squeak in the 2.x era but was merged back in 3.6, though it soon forked again. Since an implementation of Etoys was still included in Squeak, this fork was not always obvious. It would be nice to merge the two systems again and having an optional Etoys package that can be cleanly loaded into the official Squeak is a good way of doing that. And here we come back to the subject of this thread - why is FFI not included in the official Squeak VM? It is possible to use the security plugin to make sure no expression you can type into Squeak can mess up your system. It is still trivial to crash Squeak itself (we are not talking about the eSqueak kind of security) but you will only be able to write files to one directory on the whole disk. If FFI is available, however, then no restrictions can be enforced. That is not good in some commercial contexts, but it would also make convincing schools to install Squeak on their computers much harder than it already is. Unfortunately that battle was lost - VPRI gave up trying to work around school IT policies and takes advantage, in several of the projects in the list I mentioned above, of the fact that Javascript is already there. Note that using the OSProcess plugin has more or less the same security issues as FFI. So including them in the official VMs is something that shouldn't be done lightly. -- Jecel |
In reply to this post by kilon
On 18 August 2012 22:56, dimitris chloupis <[hidden email]> wrote:
> I thought e-toys was the main reason between the chasm between pharo and > squeak, does that mean there is an intetion to reunite the two projects ? I > am curious where squeak and pharo are going and I am worried how easy it > will be for me to use libraries from both projects. > Pharo is going to into direction of having FFI by default. And i must stress, this is not because of me or my personal bias, or advocacy. This is what people want and constantly bugging us with. > Nope I would not want to remove ctypes from python, its inclusion makes it > possible to run python applications that use ctypes with zero installation > in OS that come with python included which is both Macos and Linux. That > means that out of the python can use any native library. Opengl is a big > example. Add to that that in macos Apple has implemented pyobjc which takes > FFI a step further that makes it possible to use any pyobjc library and even > pyobjc libraries to use python.And that in my book is a clear win . Not only > to include an FFI but also an extra layer that further automates interfacing > with native libraries as if they are libraries made for that particular > language. I see Squeak FFI tries to do something similar. > > Well installing FFI win32 on Macos for me at least has not been painless. It > fails, I promise to reply back with the exact error. Also is there a > "install" button, because I really missed it. I am on vacations and I have > to download the files in another computer and install them in a diffirent > computer. Because my macbook air has no ethernet port and the internet pc > modem has no wifi.But that is not an issue as soon as I return back home. > > > ________________________________ > From: Chris Muller-3 [via Smalltalk] > <[hidden email]> > To: kilon <[hidden email]> > Sent: Saturday, 18 August 2012, 20:02 > Subject: Re: Why FFI is not included with latest squeak ? > >> " Many applications do not need FFI" that could be said for a lot of >> smalltalk libraries already included with squeak. For example I have not >> seen many apps in squeak source make use of etoys ( I love etoys by the >> way >> and one of the reason I prefer Squeak from Pharo and is potentially >> necessary for a project I am making). I dont think that is a good excuse >> as >> well... > > We want to remove Etoys from the base image as well. > >> In any case I asked the question not because I want to force the inclusion >> of FFIs but because its the first time in last decade or so that I use a >> language implementation that does not come included with an FFI and tham > > We've tried to make installation of FFI as painless as possible. It > doesn't seem so bad to just have to click "install". Maybe the other > languages should follow this paradigm instead of including it... > > > > ________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264p4644547.html > To unsubscribe from Why FFI is not included with latest squeak ?, click > here. > NAML > > > > > -- Best regards, Igor Stasenko. |
In reply to this post by Yanni Chiu
On 17 August 2012 22:21, Yanni Chiu <[hidden email]> wrote:
> On 17/08/12 2:46 PM, Lawson English wrote: >> >> >> Which is a huge downside to the current implementation of NativeBoost, >> although, in theory, you could create a version that would compile to C >> via slang rather than using Igor's x86 assembler syntax. > > > But it's called *Native*Boost. Are you suggesting non-native boost? Wouldn't > that be Cog/JIT? > Right. It is native. You can talk directly to metal. No layers on top.. you are the in total control. This is the main motivation behind a project. You can build abstractions on top of it, of course. And of course you can make it portable across as many platforms as you need.. It may be hard but it is doable. But conceptually one thing are not gonna change: you have direct access to machine code, which means no compiler standing in your way, which generating suboptimal code :) And for some cases it is simply impossible to implement things in C without heavy sacrifices in speed.. consider arithmetic overflow - in CPU's you have a flag which indicates that.. but in C there is no way how you can access it.. so you cannot just write: int a, b; if ( (result = a +b) > maxInt ) { .. switch to big integer arithmetic .. } and i guess you can find many other cases where direct machine code is more preferable than produced by compiler(s). -- Best regards, Igor Stasenko. |
In reply to this post by Bert Freudenberg
On 19 August 2012 00:11, Bert Freudenberg <[hidden email]> wrote:
> No, Etoys is not the main reason for the Squeak/Pharo split. There are quite > a few Pharoers who like Etoys, but pretty much nobody likes its > implementation, with the original design barely visible under all the hacks > accumulated over the years. > +1 Actually i never heard things like "i hate Etoys" from Stef or Marcus.. or any other pharoers. I think it is great concept and very nice idea.. but implementation, its quality, this is what people didn't liked and that was the main motivation for cutting it from image. > One difference between Pharo and Squeak is that we Squeakers want to make > Etoys unloadable but keep it working, whereas in Pharo it was just removed. > > One of Pharo's main goals is getting a clean base system quickly, even if > that means breaking lots of things that used too work. In Squeak we value > backwards compatibility higher, even if that means cleaning the system takes > longer. > > - Bert - > > On 18.08.2012, at 23:56, dimitris chloupis <[hidden email]> wrote: > > I thought e-toys was the main reason between the chasm between pharo and > squeak, does that mean there is an intetion to reunite the two projects ? I > am curious where squeak and pharo are going and I am worried how easy it > will be for me to use libraries from both projects. > > Nope I would not want to remove ctypes from python, its inclusion makes it > possible to run python applications that use ctypes with zero installation > in OS that come with python included which is both Macos and Linux. That > means that out of the python can use any native library. Opengl is a big > example. Add to that that in macos Apple has implemented pyobjc which takes > FFI a step further that makes it possible to use any pyobjc library and even > pyobjc libraries to use python.And that in my book is a clear win . Not only > to include an FFI but also an extra layer that further automates interfacing > with native libraries as if they are libraries made for that particular > language. I see Squeak FFI tries to do something similar. > > Well installing FFI win32 on Macos for me at least has not been painless. It > fails, I promise to reply back with the exact error. Also is there a > "install" button, because I really missed it. I am on vacations and I have > to download the files in another computer and install them in a diffirent > computer. Because my macbook air has no ethernet port and the internet pc > modem has no wifi.But that is not an issue as soon as I return back home. > > > ________________________________ > From: Chris Muller-3 [via Smalltalk] > <[hidden email]> > To: kilon <[hidden email]> > Sent: Saturday, 18 August 2012, 20:02 > Subject: Re: Why FFI is not included with latest squeak ? > >> " Many applications do not need FFI" that could be said for a lot of >> smalltalk libraries already included with squeak. For example I have not >> seen many apps in squeak source make use of etoys ( I love etoys by the >> way >> and one of the reason I prefer Squeak from Pharo and is potentially >> necessary for a project I am making). I dont think that is a good excuse >> as >> well... > > We want to remove Etoys from the base image as well. > >> In any case I asked the question not because I want to force the inclusion >> of FFIs but because its the first time in last decade or so that I use a >> language implementation that does not come included with an FFI and tham > > We've tried to make installation of FFI as painless as possible. It > doesn't seem so bad to just have to click "install". Maybe the other > languages should follow this paradigm instead of including it... > > > > ________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Why-FFI-is-not-included-with-latest-squeak-tp4644264p4644547.html > To unsubscribe from Why FFI is not included with latest squeak ?, click > here. > NAML > > > > > > -- Best regards, Igor Stasenko. |
Free forum by Nabble | Edit this page |