Why FFI is not included with latest squeak ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Why FFI is not included with latest squeak ?

kilon
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 ?
Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

Chris Muller-3
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.
>

Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

Bert Freudenberg
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.
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

LawsonEnglish
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


Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

Yanni Chiu
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?



Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

LawsonEnglish
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


Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

kilon
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.
>>
>





Reply | Threaded
Open this post in threaded view
|

How may I contribute in documenting classes ?

kilon
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.
>>
>









Reply | Threaded
Open this post in threaded view
|

Re: How may I contribute in documenting classes ?

kilon
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 ? 





Reply | Threaded
Open this post in threaded view
|

Re: How may I contribute in documenting classes ?

radoslav hodnicak
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:
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.
>>
>













Reply | Threaded
Open this post in threaded view
|

Re: How may I contribute in documenting classes ?

Frank Shearar-3
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.
>>>
>>
>
>
>
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: How may I contribute in documenting classes ?

kilon
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




Reply | Threaded
Open this post in threaded view
|

Re: How may I contribute in documenting classes ?

Nicolas Cellier
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
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

Chris Muller-3
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...

Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

kilon
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




Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

Bert Freudenberg
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 -

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





Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

Jecel Assumpcao Jr
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


Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

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.

Reply | Threaded
Open this post in threaded view
|

Re: Why FFI is not included with latest squeak ?

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.

123