November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] The Second Coming of Java article

by Marcus Denker

On 25 Nov 2013, at 21:13, kilon alios <kilon.alios(a)gmail.com> wrote: > I don't see a problem. Sockets provide a way to communicate, sockets nowadays are used almost everywhere. They have their limitations but its a viable , very fast and simple solution. > > Also you can use Redline Smalltalk -> http://www.redline.st/ if you want to run smalltalk on JVM. > > I vaguely remember that Squeak had the Ometa project that was working as a converter between languages , I think Java was supported. > Keep in mind that supporting syntax is one thing, semantics is the otherâ¦ Ometa is just a (very nice) tool for making implementing a parser for syntax easier, very much like PetitParser. I once did a very, very naive demo of adding other *syntax* to Squeakâ¦ http://www.slideshare.net/MarcusDenker/a-programming-language-babel But the problem is that the *semantics* are still that of Smalltalk, and itâs completely not clear for the programmer where the similarity ends. If you want to have âI can type in examples from my ruby bookâ compatibility, you need to implement the real semantics, which in many cases means to re-implement the VM of that other language (in a very slow version) on top of your VM which does not really have the properties to support those semantics. There has been more research recently about multi-language VMsâ¦ or frameworks to build VMs (PyPy, for example). Without this support, getting 100% correct semantic *and* be fast enough (not even fast) is very hard. Marcus

Nov. 25, 2013

Re: [Pharo-dev] The Second Coming of Java article

by kilon alios

I don't see a problem. Sockets provide a way to communicate, sockets nowadays are used almost everywhere. They have their limitations but its a viable , very fast and simple solution. Also you can use Redline Smalltalk -> http://www.redline.st/ if you want to run smalltalk on JVM. I vaguely remember that Squeak had the Ometa project that was working as a converter between languages , I think Java was supported. Plenty of options already. On Mon, Nov 25, 2013 at 9:54 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 25/11/13 19:17, kilon alios wrote: > >> Its also way simpler and faster to just make java apps communicate with >> pharo via sockets. >> > > No, it's not simpler nor faster. > Imagine you want to parse and validate XML using Xerces parser > while having your SAX handler written in Smalltalk. > > Jan > >

Nov. 25, 2013

Re: [Pharo-dev] about miniimage

by StÃ©phane Ducasse

> > From the practical point of view, it's always faster to remove. something than to load something. And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy. > > Tangentially can anyone point me to a headless image with a REPL for use in testing Spur? Guillermo has several bootstrapped and minimal images. I tried to find them but I could not https://ci.inria.fr/pharo-contribution/job/Bootstrap/ Guillermo? Is now on holidays. I will look around. Stef

Nov. 25, 2013

Re: [Pharo-dev] about miniimage

by StÃ©phane Ducasse

On Nov 25, 2013, at 7:11 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi Stef, > > our starting point looks like this: > - we have a method how to produce small image without network etc. > - we are able to load network, Monticello and Gofer in it (this job is currently broken) > - we are able to load Metacello too - this should be the basic stage for normal users I would love to be able to grab an image up to the previous stage. Like that I can continue to work on the configurations regeneration project I have > - than we are a le to load rest od the system at once > - we have several configurations that we are able to load and unload. > > Our biggest problem is the huge nonmodular step between Metacello image and full Pharo. I think we shoud move forward using division. To define how an image without development tools should look like and create two big configurations for them. Then continue with the next splitting. Yes > > From the practical point of view, it's always faster to remove. something than to load something. Fun since it was difficult for me to unload I thought that I should focus on load :) > And it's much faster to unload it without Monticello. So I would use ugly removeAllButPackages: because it's fast, then fix the problems like obsolete classes an Undeclared, continue with the pretty unloding part of the configuration and finally loading part will be easy. > > -- Pavel > > 24. 11. 2013 v 22:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Hi pavel >> >> may be I should start from your miniimage and start to making sure that the configurations can load then in a second step >> I can make sure that they can unload. >> >> What do you think? >> >> Stef >

Nov. 25, 2013

Re: [Pharo-dev] MCRepository can notify by email, did you know?

by StÃ©phane Ducasse

never heard about it :) On Nov 25, 2013, at 3:39 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi, > > I just discovered this feature and wanted to share it: > > When a version is saved, the file repositories check if a file named 'notify' exists in the repository directory [1]. If it exists, then it reads email addresses from that file and send emails notifying the new version [2]. > > We noticed with Camillo that this seems to be the only usage of SMTPClient in the image. > > I wonder if somebody is using this feature. > > Best regards, > MartÃn > ps: I'm talking of Pharo 3. > > [1] MCFileBasedRepository>>notifyList > [2] MCVersionNotification>>notify:

Nov. 25, 2013

Re: [Pharo-dev] The Second Coming of Java article

by Jan Vrany

On 25/11/13 19:17, kilon alios wrote: > Its also way simpler and faster to just make java apps communicate with > pharo via sockets. No, it's not simpler nor faster. Imagine you want to parse and validate XML using Xerces parser while having your SAX handler written in Smalltalk. Jan

Nov. 25, 2013

Re: [Pharo-dev] EyeInspector looks broken

by Marcus Denker

On 25 Nov 2013, at 20:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > it was done. > There is already a fixâ¦ will be added with the next update. > On Nov 25, 2013, at 10:47 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> On 2013-11-24, at 20:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> Smalltalk tools openBrowser >>> produces an emergency evaluator. >>> => annoying. >> >> => open a bug entry > >

Nov. 25, 2013

Re: [Pharo-dev] EyeInspector looks broken

by StÃ©phane Ducasse

it was done. On Nov 25, 2013, at 10:47 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-11-24, at 20:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Smalltalk tools openBrowser >> produces an emergency evaluator. >> => annoying. > > => open a bug entry

Nov. 25, 2013

Re: [Pharo-dev] New configuration for XMLWriter!

by StÃ©phane Ducasse

I published the package. It was probably in my package cache. Let me know if this is working. On Nov 25, 2013, at 10:41 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Stef, > > ConfigurationOfXMLWriter does not work. The moose build fails because XML-Writer-Core-monty.5 does not seem to exist: > > FAILED->XML-Writer-Core-monty.5[31mCould not resolve: XML-Writer-Core [XML-Writer-Core-monty.5] in /builds/workspace/moose-5.0/package-cache http://smalltalkhub.com/mc/Pharo/XMLWriter/main/ > > I did not have time to look into the problem. Could you take a look? > > Doru > > > > On Sun, Nov 24, 2013 at 6:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I created a new configuration based on the work on monty for the XMLWriter. Please test and let us know. > In PharoExtras/XMLWriter and available via the configurationBrowser. > > Thanks Monty > > Stef > Working on the new configurationOfXMLParserâ¦. > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Nov. 25, 2013

Re: [Pharo-dev] New configuration for XMLWriter!

by StÃ©phane Ducasse

I will have a look. Stef > Hi Stef, > > ConfigurationOfXMLWriter does not work. The moose build fails because XML-Writer-Core-monty.5 does not seem to exist: > > FAILED->XML-Writer-Core-monty.5[31mCould not resolve: XML-Writer-Core [XML-Writer-Core-monty.5] in /builds/workspace/moose-5.0/package-cache http://smalltalkhub.com/mc/Pharo/XMLWriter/main/ > > I did not have time to look into the problem. Could you take a look? > > Doru > > > > On Sun, Nov 24, 2013 at 6:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I created a new configuration based on the work on monty for the XMLWriter. Please test and let us know. > In PharoExtras/XMLWriter and available via the configurationBrowser. > > Thanks Monty > > Stef > Working on the new configurationOfXMLParserâ¦. > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Nov. 25, 2013