January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] Could we keep Pharo-dev for Pharo-dev?

by Norbert Hartl

Absolutely! Norbert > Am 15.01.2015 um 08:24 schrieb stepharo <stepharo(a)free.fr>: > > Hi guys > > I will start to be picky about the mails to which I reply or even read. > We should be more disciplined. Pharo-dev should be about Pharo-dev this is important > for our concentration. > I really like the other discussions but we should have them in Pharo-users. > I think that it makes sense. > > Stef >

Jan. 15, 2015

Re: [Pharo-dev] Could we keep Pharo-dev for Pharo-dev?

by Serge Stinckwich

+1 On Thu, Jan 15, 2015 at 8:24 AM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I will start to be picky about the mails to which I reply or even read. > We should be more disciplined. Pharo-dev should be about Pharo-dev this is > important > for our concentration. > I really like the other discussions but we should have them in Pharo-users. > I think that it makes sense. > > Stef > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 15, 2015

Re: [Pharo-dev] [Pharo-users] Could we keep Pharo-dev for Pharo-dev?

by Tudor Girba

+1 Doru On Thu, Jan 15, 2015 at 8:24 AM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I will start to be picky about the mails to which I reply or even read. > We should be more disciplined. Pharo-dev should be about Pharo-dev this is > important > for our concentration. > I really like the other discussions but we should have them in Pharo-users. > I think that it makes sense. > > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 15, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by kilon alios

Lets see the big picture here, if you take a look at TIOBE INDEX or LANGPOP or the internet at large you get a clear picture about java based languages . Popularity wise they have been a ultimate failure. Right now the only language that is barely noticable is Scala and even Scala is nowhere near as popular as the less popular languages like Pascal, Delphi and Visual Basic. Of course each website gives diffirent numbers but those numbers are just different in only few percentage units. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://langpop.com/ Hype also does not help those languages either. Take a look at Clojure , one of the most overhyped languages out there not just on JVM but anywhere, in both websites I mentioned Clojure like Pharo does not make it even in top 50. Tons of blogs post about Clojure only, tons of praise, and praise and praise. I can say about jython itself , a python implementation for the JVM and ironpython which is python for .NET are barely noticable in the python world with cpython gathering at least 99.9% of the attention. So its a really hard situation . Coding has become extremely complex and demanding , coders want languages are deeply documented and come with tons of libraries so its very hard for new languages to kick in. Also the assumption that because you love a language you will be willing to start using java libraries seems to have failed miserably. These languages seem more appealing to java developers and java developers dont seem willing to abandon Java any time soon. So as always Java death has been greatly exaggerated. The situation for Javascript based languages is even worse. So frankly what has happened with Redline is pretty normal. On Thu, Jan 15, 2015 at 2:36 AM, Craig Latta <craig(a)netjam.org> wrote: > > > Shaking the hive can certainly have a positive outcome, but you can > > also get you bitten. :) > > Sure, and shaking the hive too rarely will get you starved. > > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > >

Jan. 15, 2015

Could we keep Pharo-dev for Pharo-dev?

by stepharo

Hi guys I will start to be picky about the mails to which I reply or even read. We should be more disciplined. Pharo-dev should be about Pharo-dev this is important for our concentration. I really like the other discussions but we should have them in Pharo-users. I think that it makes sense. Stef

Jan. 15, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by stepharo

Le 15/1/15 00:30, Sebastian Sastre a Ã©crit : > On the other hand we are fragmented and compartamentalized big time. > > Itâs 2015 and I never had hear about this before (from 2013): > http://bulenkov.com/2013/04/23/smalltalk-support-in-intellij-idea/ > > Something like that would give you the power of all the Java libraries. > > Are you feeling it? > > Thatâs exactly the propeller that Clojure has used to go where it is now. > > > >> On Jan 14, 2015, at 9:24 PM, Esteban A. Maringolo >> <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >> >> Picking up and promoting inactive projects just to put a tick on a >> feature's checkbox can backfire big time. >> >> If there is one thing I've been always proud as a Smtalltalker is that >> we don't sell hype or vaporware, rather the contrary (which is also a >> failure). >> >> I'm all in to embrace an aggressive PR campaign, but only if properly >> curated. >> >> Regards! >> >> Esteban A. Maringolo >> >> >> 2015-01-14 19:55 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu >> <mailto:sven@stfx.eu>>: >>> A blank. >>> >>> Nothing happened to this project in more than a year >>> >>> https://github.com/redline-smalltalk/redline-smalltalk/commits/master >>> >>> It is mostly vapourware and has no users. >>> >>> People following the links on the article will soon find out. >>> >>> Just sad. >>> >>>> On 14 Jan 2015, at 23:40, horrido <horrido.hobbies(a)gmail.com >>>> <mailto:horrido.hobbies@gmail.com>> wrote: >>>> >>>> http://www.infoworld.com/article/2867543/java/redline-smalltalk-bridging-sm… >>>> <http://www.infoworld.com/article/2867543/java/redline-smalltalk-bridging-sm…> >>>> >>>> Note the last paragraph. Our campaign will be noticed! >>>> >>>> This is exactly what I was after when I started the SRP. Spread the >>>> word >>>> about the campaign as far and wide as I could. >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612.html >>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>> Nabble.com. >>>> >>> >>> >> >

Jan. 15, 2015

Re: [Pharo-dev] Hosting the Pharo VM on MirageOS

by Alain Rastoul

Le 15/01/2015 07:38, Alain Rastoul a Ã©crit : > > And yo uget a standard vm, call it NOS, NONOS or whatever :) > > BTW thinking to that it could be still much lighter and more specialized than most linux distros (no dameons, less libraries etc). Expressing smalltalk libraries dependencies in the sat solver should be possible. I'll dig into the mirage discussion and links later, I'm interested too -- Regards, Alain

Jan. 15, 2015

Re: [Pharo-dev] Hosting the Pharo VM on MirageOS

by Alain Rastoul

Le 15/01/2015 03:08, Joerg Beekmann, DeepCove Labs a Ã©crit : > > I was not planning specializing the VM for the image. But rather link in a VM with everything needed to run > a range of images. The dependencies are handled by creating an OCAML module that expresses these and the > VM code then lives in the module. The OCAML dependence analyser (a sat solver) then ensures those are satisfied. > But if you don't have a specialized smalltalk vm and image, you will have to embed full system dependencies, in order to build a full working smalltalk system (having most part not working could be a very bad thing), and then you loose the unikernel approach benefits (very lean dedicated system, small attack surface etc.). And yo uget a standard vm, call it NOS, NONOS or whatever :) May be have a look at Spoon (suggested by Craig) and Seed and Hazelnut http://rmod.inria.fr/web/software/Seed -- Regards, Alain

Jan. 15, 2015

Re: [Pharo-dev] Hosting the Pharo VM on MirageOS

by Joerg Beekmann, DeepCove Labs

> -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of > Alain Rastoul > Sent: Tuesday, January 13, 2015 11:10 PM > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Hosting the Pharo VM on MirageOS > > Le 14/01/2015 04:39, Joerg Beekmann, DeepCove Labs a Ã©crit : > > Hi > > > > I've been exploring the possibility of hosting the Squeak/Pharo VM on > MirageOS. MirageOS is a Unikernal or "Library OS" where rather than creating > an executable to be run on Linux the compiler analyses dependencies right > down through the device drivers and creates a kernel that can be booted on > Amazon AWS EC2. > > http://www.openmirage.org/ > > http://queue.acm.org/detail.cfm?id=2566628 > > > > http://blog.acolyer.org/2015/01/13/unikernels-library-operating-system > > s-for-the-cloud/ > > > > It seems to me that having a Smalltalk hosed in this environment would be > quite useful on a number of fronts: > > * A simple build and deploy of Smalltalk to the cloud. The Mirage group is > building unikernals from sources and then because they are small committing > the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites > and APIs are an obvious application. http://amirchaudhry.com/from-jekyll-to- > unikernel-in-fifty-lines/. > > * Smalltalk on small devices. The Mirage group is running Xen with mirage on > small Intel and ARM boards. See http://openmirage.org/blog/announcing- > mirage-20-release/. > > * These kernels can be very small, on the order of 0.25Meg for minimal HTTP > servers with boot times in the ms range. A project called Jitsu > https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in > response to socket requests. The system making the request is unaware of the > boot. > > * The Mirage group envisions thousands of kernels running on a single > Hypervisor with his speed inter-kernel communications. See > http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems > consisting of a swarm of communicating images where each image is single > threaded and concurrency is via message passing. > > > > I've corresponded with the MirageOS group asking if they thought a language > VM could be hosted on Mirage. The discussion is here: > http://lists.xenproject.org/archives/html/mirageos-devel/2015- > 01/msg00053.html. Assuming we understood each other it seems the answer > is "yes that should be possible". > > > > My question is what would be involved on the Smalltalk side? I presume the > effort is going to be mostly in the VM. Based on the conversation on the Mirage > list I think the VM will need to be able to run a Library with an entry point called > by Mirage. That seems similar to the " Embedding/VM as a DLL" project > proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this > project active? The comment indicates this is mostly refactoring & > repackaging. Anyone have a perspective on this? > > > > Best regards > > > > Joerg > > > > > > > > > > > > Hi, > > I've been thinking on that kind of question from a different point of > view: cutting an application > in parts, and running several single core pharo vm in different xen vms with > inter domain communication (or network communication if clustered on > different hosts) in order to achieve multi core processing. > For ipc communication, I found libvchan , whose documentation seems to be > only the xen source code and a small sample in the code, and the vicent > bernadoff open mirage post (no a lot of doc) and I also found xen sockect, an > older paper here > http://www.researchgate.net/publication/221461399_XenSocket_A_High- > Throughput_Interdomain_Transport_for_Virtual_Machine/links/00b7d51cb10e > c74e9b000000.pdf > that look interesting because it has the same api as sockets, but no more > information, it seems to be only an old research paper. > Forthe last one, it has been be done on top of grant table and could probably be > written but I guess not trivial at all. For an example of some work being done in this area by the mirage group see: http://openmirage.org/blog/update-on-vchan. They seem to have come some way with this. Here is the bottom line. I've seen no sign of the next post. "vchan is a very low-level communication mechanism, and so our next post on this topic will address how to use it in combination with a name resolver to intelligently map connection requests to use vchan if available, and otherwise fall back to normal TCP or TCP+TLS." > About openmirage, since the unikernel has to deal with code dependencies, > how to integrate the dependency analyser with smalltalk code in order to build > a specialized vm ? I was not planning specializing the VM for the image. But rather link in a VM with everything needed to run a range of images. The dependencies are handled by creating an OCAML module that expresses these and the VM code then lives in the module. The OCAML dependence analyser (a sat solver) then ensures those are satisfied. > And about your idea of running the vm in a dll, how will it manage primitives in > specialized libraries ? That I don't know. Probably pick a reasonable set of default primitives. I'll note the idea of the VM as a dll was not mine but rather seemed to be a proposed project on Eliot's Cog Blog. > I suppose you would also have to go into the dependency toolchain to describe > pharo packages dependencies in terms of openmirage functionality > dependencies ? > > May be you could also look at Android port of pharo, since it runs the vm as a jni > dll ? I will thanks! > But the primitive part of android port (libraries) do not have to deal with > dependencies since android is based on linux. Mirage is also Linux in a sense. It You can run Mirage applications as user executable on Linux. That is how they are typically debugged. The cool idea is to then say "lets perform whole system dependency analysis and build a Kernel with only what our application needs". > > -- > Regards, > > Alain > Hi Alain

Jan. 15, 2015

Re: [Pharo-dev] InfoWorld on Redline Smalltalk

by Craig Latta

> Shaking the hive can certainly have a positive outcome, but you can > also get you bitten. :) Sure, and shaking the hive too rarely will get you starved. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Jan. 15, 2015