Thanks Tim. I even tried to find the old Potatoe Smalltalk which was a port of an old Smalltalk-80 image as it had a working ide and yet the smallest count of classes.
Sent from my Commodore 64 > On 31 Dec 2016, at 1:01 am, Tim Mackinnon <[email protected]> wrote: > > I think we've gone off topic - James would simply like advice on what a > minimal image could/should be composed of. > > That doesn't sound like a lot of work to help with that. > > I know there is a minimal image project in Pharo, but I'm not sure how > minimal it got. I recall Marcus once telling me that the trick might be to > get things to a place where you could bootstrap metacello and load in > whatever you needed. I'm not sure if that is still the goal? But that would > strike me as the core library he's interested in? > > Equally there was some work around having a scripting language using a > command line Pharo for build type things. I don't recall its name - but again > I'm sure it relies on a core set of classes that are used to bootstrap stuff > as well. > > If someone can point to either of those two things that might help James > enough. > > I know his actual project is hosted in GitHub and doesn't really distract > anything going on here. It's on my todo list to check it out. > > Tim > > Sent from my iPhone > >> On 30 Dec 2016, at 13:49, Dimitris Chloupis <[email protected]> wrote: >> >> The problem for an open source community as this one is time and money >> >> As Stef says "give me a million dollars and I will give you a Pharo million >> times better" >> >> that's the dream world >> >> in real world we all have very limited time that we focus on the sides of >> Pharo that interest us the most. Obviously we are here to help people use >> Pharo under any condition and requirement. As such I think and hope that I >> speak for everyone that we are more than happy to offer advice to help Pharo >> extend its influence on other platforms. >> >> To actually contribute code will need Pharo developers that are experienced >> Java developers too (I am not). >> >> Problem is that neither Java nor Javascript have good reputation and as such >> people who can avoid them do so. >> >> For example even though we can justify the freeze of a project like Redline >> Smalltalk because of the tiny size of the Smalltalk community but take >> something huge in popularity like Python, the official release of Python is >> CPython with an estimate of over 2 million developers world wide , Jython >> which is the port of Python in JVM has actually smaller community than we >> have at least last time I checked few gears ago. Just think about it for a >> minute. >> >> Its super hard to convince a python developer to switch to jython and so is >> for a java developer. >> >> This applies for all languages, I think the reasoning is that each language >> is not just a tool but an entire culture and people pick them for specific >> reasons, >> >> Javascript situation is more or less the same, python has no actively >> supported javascript equivelant. >> >> Again I am using Python as an example, different languages same or similar >> scenario. >> >> This is why I suggested to bring Redline closer to Pharo rather than porting >> some Pharo classes to JVM. >> >> Amber failed to gain traction because it did the opposite of what I am >> suggesting , tried to convince people to give up Pharo and move completely >> to Amber (for the JS part) which is why it implemented its own IDE etc. >> Obviously it did not work and Amber is barely alive. >> >> PharoJS seem on the right path , at least for me, so maybe there is still >> hope. >> >> In any case its not hard to use libraries from other programming language in >> Pharo with some form of IPC, I do this for using python libraries from Pharo >> and I making something similar for C++. Took me only a few hundred lines of >> code to do it for both and works pretty well. IPC can work with pretty much >> any language and as many languages at the same time as you want or your >> processor can handle. >> >> There are a ton of projects out there that use multiple languages that work >> together as one unit. Problem is that you can approach this through a >> billion diffirent angles and it will depend on the specific problem you want >> to solve. I build my own IPC tools to fit my specific needs which are Unreal >> (game engine) and Blender (3d application). >> >> There was a cool idea from a presentation a Smalltalker once gave about >> moving a DigiTalk implementation to JVM whithout changing a thing inside the >> image. Instead they ported the bytecode from smalltalk to JVM and used JNI >> for the C libraries. Sound too good to be true, they supposed to release it >> open source ages ago but that turned out to be another vaporware. >> >> I also agree that Cuis is a very good start to find the most essential >> libraries for Pharo. There is also a minimal image for pharo on the dowload >> section of the website which should give a good idea. But as it is to be >> expected its impossible to predict what is essential for each Pharo user and >> there lies the challenge. >> >>> On Fri, Dec 30, 2016 at 1:59 PM Tim Mackinnon <[email protected]> wrote: >>> Actually I think James is on to something and we should try and support him. >>> >>> Having recently played with AWS Lambda and written a few Alexa services in >>> JS, I was intrigued how you would approach such end points in Smalltalk >>> and whether it would be a productive language and environment to run them >>> in. (Btw - the lambda environment is very interesting - scalable >>> infrastructure that is peanuts to run). >>> >>> To try this, the basic building blocks provided by these services are >>> either JS or Java - so for Smalltalkers that sounds like Smalltalk running >>> on Amber or Redline. >>> >>> I find Amber and all the JS infrastructure very daunting - gulp, amd etc. >>> And for Lambda you also get caught into this world of package management >>> and loading up JS dependencies. >>> >>> I'm intrigued how a jvm Smalltalk might approach this problem (as well as >>> many others I'm sure). We seem to achieve a lot with quite a small image of >>> building blocks. >>> >>> As pharo is a research community, can we help James explore this a bit >>> more? Certainly there is a drive to a minimal Smalltalk image - so that >>> work can immediately feed into this. >>> >>> To add to the research'y side context - these service infrastructures seem >>> to feel a lot like callable blocks of code. We are used to thinking in this >>> way in our image - we use blocks everywhere. How might they run in a >>> scaleable environment vs straight function call languages? >>> >>> Tim >>> >>> Sent from my iPhone >>> >>>> On 30 Dec 2016, at 09:31, Dimitris Chloupis <[email protected]> wrote: >>>> >>>> I think what most people would want is to use Java libraries from inside >>>> Pharo. You seem to want to bring Pharo classes to Redline Runtime . >>>> >>>> I have the opposite idea of bringing Redline Runtime inside Pharo and give >>>> us Pharo developers an easy way to use Java libraries and mix pharo with >>>> java code. I think also Pharo would serve great as an IDE for Redline >>>> Smalltalk. >>>> >>>> I already have JNIPort thats does that but none will complain to have >>>> another tool around, I am sure it will come very handy. >>>> >>>> On Fri, Dec 30, 2016 at 2:08 AM James Ladd <[email protected]> wrote: >>>> Hi Pharo People, >>>> >>>> I have continued work on Redline Smalltalk and I'm wanting to discuss what >>>> the absolute minimum >>>> set of Classes and method should be included in the Redline Runtime. >>>> >>>> Would anyone here like to participate in that discussion? >>>> >>>> - James. >>>> Redline Smalltalk <http://redline.st> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/Redline-Talking-Runtime-basics-tp4928375.html >>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>> Nabble.com. >>>>
