On 19 August 2012 00:11, Bert Freudenberg <bert at freudenbergs.de> 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 <thekilon at yahoo.co.uk> 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]
> <ml-node+s1294792n4644547h30 at n4.nabble.com>
> To: kilon <thekilon at yahoo.co.uk>
> 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.