February 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Why Smalltalk is not popular?

by J.F. Rick

On Wed, Feb 12, 2014 at 8:44 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Honestly it was fun in 1999... it gets boring after a while ;-) > Just because Smalltalk is not currently popular doesn't mean that it can't be in the future. The key, to me, is finding a killer application. For instance, Processing could have been written in Smalltalk rather than Java. It would have been a great vehicle to popularize Smalltalk but the opportunity was not taken. Scratch is cool but is (1) increasingly divorced from its Smalltalk origins and (2) does not provide a good bridge to full-on Smalltalk. Perhaps Phratch can do a better job of providing that pathway. If we are interested in making Smalltalk more popular, thinking about what we can do to make it more accessible, useful, etc. makes sense. It also can be useful to examine the failures of the past in order to not repeat them. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Feb. 13, 2014

Fwd: Request

by Guido Chari

Hi guys, IÂ´m doing some experiments with dynamic primitives and files. Actually i am working with the socket and file plugin. (In that order of priority) Does anyone know about an open pharo app that make heavy use of sockets (mainly creating lot) that i can borrowed (install locally) for doing serious experiments? Something with heavy used of files will help too. Thanks, Best, Guido.

Feb. 13, 2014

SqueakSSL fixes

by GÃ¶ran Krampe

Hey! Ok, so I sat down and "packaged" some fixes to mainly iOS SqueakSSL that we have done here at 3DICC. We have no intention to keep stuff like this for ourselves, but daily we work using our own repos so it needs some attention and time to get it out there :) Sorry if this email is long but I just wanted to make it easy for people to know how to integrate this. The fixes span: * A new SqueakSSL Monticello package, that has other fixes too done at 3DICC. I haven't looked through them all in detail, so here a bit of manual cherry picking is needed. For example we removed some "compatibility code" for Squeak 4.2 causing us some problems. * Modified platform files: platforms/Cross/plugins/SqueakSSL/SqueakSSL.h platforms/iOS/plugins/SqueakSSL/sqMacSSL.c platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.c platforms/win32/plugins/SqueakSSL/sqWin32SSL.c I have so far only tested the new sqMacSSL.c on iOS - OSX 10.8.5. The changes in the other platforms are not complicated, its about being able to disable certificate check mainly so I don't think they should fail. As of now SqueakSSL-Tests show 14 run, 3 passes, 8 expected failures and 3 errors on my Mac. The errors still left are: testSSLSockets, testSocketAccept, testSocketConnect. AFAIK all these try to use a test certificate and Accept - and *that* I haven't implemented on Mac (well, ok, I started - there is a way to at least set a Mac test cert into the plugin - but I didn't go further). New methods in the classes: SqueakSSL,SecureSocketStream>>certVerify: aBoolean Now one can tell the plugin to verify certs or just skip that. SqueakSSL,SecureSocketStream>>logLevel: anInteger Now one can set the logLevel in the plugin, 0 or 1 so far. Attached ssl-fix.zip which contains: . âââ platforms â âââ Cross â â âââ plugins â â âââ SqueakSSL â â âââ SqueakSSL.h â âââ iOS â â âââ plugins â â âââ SqueakSSL â â âââ sqMacSSL.c â âââ unix â â âââ plugins â â âââ SqueakSSL â â âââ sqUnixOpenSSL.c â âââ win32 â âââ plugins â âââ SqueakSSL â âââ sqWin32SSL.c âââ SqueakSSL-Core-gk.36.mcz âââ SqueakSSL-Tests-ar.17.mcz âââ ssl-fix.patch I threw in the latest SqueakSSL-Core and Tests that we have here at 3DICC. The Tests package is the same as on SS. The Core has 4 more fixes from Ron I think, just look in "History" to see commit messages there. ssl-fix.patch - this should show you what I have done in the platform files, and I produced it using git diff on those four files with this command: git diff 83bce99715cddd8a82c3d94c487e45ec0213be19 platforms/Cross/plugins/SqueakSSL/SqueakSSL.h platforms/iOS/plugins/SqueakSSL/sqMacSSL.c platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.c platforms/win32/plugins/SqueakSSL/sqWin32SSL.c > ssl-fix.patch The SHA is: commit 83bce99715cddd8a82c3d94c487e45ec0213be19 Author: Camillo Bruni <camillobruni(a)gmail.com> Date: Fri Nov 15 12:24:11 2013 +0100 fixed wrong path ------------------------------ ...phew. Ok, let me know if you need anything more and ask questions. regards, GÃ¶ran

Feb. 13, 2014

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

by Ron Teitelbaum

From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of phil(a)highoctane.be Ron, Sure but at this time, not being able to run the simulator in a full Pharo environment is a severe issue. The key advantage is that the Smalltalk VM is written in itself. Now, what do I experience is that it is hard to embark on VM work. Why? Even if the PharoVMBuilders help in generating and compiling the VM for several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc) this is only one part of the puzzle. The next step, is to understand how things do work for real, the interpret() C loop isn't gonna help me one bit, I need to be able to simulate this one in a Simulator. And I want to do that on the Pharo platform. Currently on 2.0 - this will (again) be fun to get to work on 3.0. I understand. I'm suggestion that our shared goal should be to bring the communities together for the VM. We can all benefit from the contributions on all sides. It would seem to me that the COG simulator would work for Pharo if we can get closer in sync but you are correct: It will take time, collaboration and resources. All the best, Ron Teitelbaum [snip] The core system should be the same for Pharo/Squeak/... : VMMaker-MemoryManager VMMaker-Interpreter VMMaker-InterpreterSimulation VMMaker-MemoryManagerSimulation and of course the Slang things (VMMaker-Support and VMMaker-Translation to C). What I'd love to end up with is an embeddable VM that we could hook into other environments, languages etc (a bit like TCL for example). This requires work on how the VM core runs. And to explore this, simulation is needed. Sorry for the long post. I wish I was a millionaire to pour in some cash into the project to speed some areas up. Working on it :-) Maybe should we work in that direction for funding. http://www.gv.com/ where are you? Phil On Thu, Feb 13, 2014 at 10:38 AM, Ron Teitelbaum <ron(a)usmedrec.com> wrote: > Stefan Marr > > Hi Eliot: > > On 13 Feb 2014, at 05:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Hmm. What's the easiest way to map this to a Monticello mcz so I can > integrate your changes back into my packages? > > I think the bigger question is whether you actually want to adopt those things. That the vm says in sync should be a core requirement for our communities. I realize that there is a split. There are some really great advancements going on in pharo-vm including new build methods and configurations. All of that has value if pharo can stay in sync with COG developments. It doesn't make sense to require Pharo developers to redo Eliot's work or to eliminate Pharo VM advancements from the Squeak / Newspeak community. The VM is the one place where we can continue to work together for the benefit of all three communities. We should not, if at all possible, diverge, lest we lose some excellent contributions from some really terrific people, in one or another community. All the best, Ron Teitelbaum > If you skim over the diffs on Github [1], you will probably find that most of the > changes are necessary to adopt Pharo-specific API changes. > Not sure what the best way forward would be to avoid having the two Squeak > and Pharo flavors diverge even more. > > I am open to suggestions, don't have a good idea how to properly 'modularize' > these differences myself. > > Best regards > Stefan > > [1] https://github.com/pharo-project/pharo-vm/pull/18 > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > >

Feb. 13, 2014

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

by Ron Teitelbaum

> Stefan Marr > Hi Ron: > > On 13 Feb 2014, at 10:38, Ron Teitelbaum <Ron(a)USMedRec.com> wrote: > > >> I think the bigger question is whether you actually want to adopt those > > things. > > > > That the vm stays in sync should be a core requirement for our communities. > > I am with you on that Ron. But I need a technical solution to manage those > things. > Good intensions are one thing, but how do we do that? > I think the answer is one at a time. With some collaboration and negotiation. Refactoring is fine as long as it provides some value. It doesn't have to be a change in function, a change in clarity suffices in my opinion. The benefit needs to be worth the pain of change. Where we can agree on the benefit the three communities should adopt it. Where we disagree, each community should take on the pain of supporting their version and we diverge. I'm confident that Eliot can manage to sync up what makes sense. Hopefully he can also push back on what doesn't and you can sync up on his changes or concerns. With the good intention as a core goal on all sides, proper action follows. All of this gets easier if we collaborate up front instead of trying to sync after the fact. All the best, Ron Teitelbaum > Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits] > > primitiveUpdateGZipCrc32 > - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: > GZipWriteStream crcTable]. > + self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC > crc32Table]. > > primitiveGetAttribute > > - attribute := Smalltalk getSystemAttribute: attr. > + attribute := Smalltalk vm getSystemAttribute: attr. > > CogVMSimulator>> initialize > - 'Display has not yet been installed' asDisplayText form. > + 'Display has not yet been installed' asMorph imageForm. > > > ioRelinquishProcessorForMicroseconds > - Processor activeProcess == Project uiProcess ifTrue: > + Processor activeProcess == UIManager default uiProcess ifTrue: > > > And so far, I only fixed trivial things. Still need to figure out what is going wrong > with more recent Pharo images. > > Best regards > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > >

Feb. 13, 2014

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

by phil＠highoctane.be

Stefan, Some changes I did. I am adding you to a dropbox folder where I've put my sim image. You can put yours in there as well. There is also the issue of FileSystem :-) Phil On Thu, Feb 13, 2014 at 11:01 AM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi Ron: > > On 13 Feb 2014, at 10:38, Ron Teitelbaum <Ron(a)USMedRec.com> wrote: > > >> I think the bigger question is whether you actually want to adopt those > > things. > > > > That the vm stays in sync should be a core requirement for our > communities. > > I am with you on that Ron. But I need a technical solution to manage those > things. > Good intensions are one thing, but how do we do that? > > Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits] > > primitiveUpdateGZipCrc32 > - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: > GZipWriteStream crcTable]. > + self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC > crc32Table]. > > primitiveGetAttribute > > - attribute := Smalltalk getSystemAttribute: attr. > + attribute := Smalltalk vm getSystemAttribute: attr. > > CogVMSimulator>> initialize > - 'Display has not yet been installed' asDisplayText form. > + 'Display has not yet been installed' asMorph imageForm. > > > ioRelinquishProcessorForMicroseconds > - Processor activeProcess == Project uiProcess ifTrue: > + Processor activeProcess == UIManager default uiProcess ifTrue: > > > And so far, I only fixed trivial things. Still need to figure out what is > going wrong with more recent Pharo images. > > Best regards > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > > >

Feb. 13, 2014

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

by phil＠highoctane.be

Ron, Sure but at this time, not being able to run the simulator in a full Pharo environment is a severe issue. The key advantage is that the Smalltalk VM is written in itself. Now, what do I experience is that it is hard to embark on VM work. Why? Even if the PharoVMBuilders help in generating and compiling the VM for several platforms (I can build for Windows 8.1, OSX, iOS, Debian 7 etc) this is only one part of the puzzle. The next step, is to understand how things do work for real, the interpret() C loop isn't gonna help me one bit, I need to be able to simulate this one in a Simulator. And I want to do that on the Pharo platform. Currently on 2.0 - this will (again) be fun to get to work on 3.0. I am not in the league of the VM maintainers obviously. But Clement provided me with Eliot's Cog Simulation image, which works for his own work. But only his own. We do not have something like a Configuration to get the same thing. And that's a very acute pain. There are only so many hours in a day, true. So, in order to bring in more people/resources for the VM work, the barrier to entry should be moved a tad down. We tried to have the StackSimulator working for a while (Stephan I'll definitely get your version, thanks for it). This is also because InterpreterSimulator doesn't work anymore and we have to use the StackInterpreter instead (which is complicated already vs pure interpreter). All of this rant to say that having a clean interpreter and a basic image (Maybe PharoKernel/Hazelnut/Boostrapping/Spoon will give us a very simple image to simulate - the whole image isn't really needed. Hopefully Oz will also move us forward on that front). A real Pharo image is overkill for this as a ton of plugins get involved etc. The core system should be the same for Pharo/Squeak/... : VMMaker-MemoryManager VMMaker-Interpreter VMMaker-InterpreterSimulation VMMaker-MemoryManagerSimulation and of course the Slang things (VMMaker-Support and VMMaker-Translation to C). What I'd love to end up with is an embeddable VM that we could hook into other environments, languages etc (a bit like TCL for example). This requires work on how the VM core runs. And to explore this, simulation is needed. Sorry for the long post. I wish I was a millionaire to pour in some cash into the project to speed some areas up. Working on it :-) Maybe should we work in that direction for funding. http://www.gv.com/ where are you? Phil On Thu, Feb 13, 2014 at 10:38 AM, Ron Teitelbaum <ron(a)usmedrec.com> wrote: > > Stefan Marr > > > > Hi Eliot: > > > > On 13 Feb 2014, at 05:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > Hmm. What's the easiest way to map this to a Monticello mcz so I can > > integrate your changes back into my packages? > > > > I think the bigger question is whether you actually want to adopt those > things. > > That the vm says in sync should be a core requirement for our communities. > I realize that there is a split. There are some really great advancements > going on in pharo-vm including new build methods and configurations. All > of > that has value if pharo can stay in sync with COG developments. It doesn't > make sense to require Pharo developers to redo Eliot's work or to eliminate > Pharo VM advancements from the Squeak / Newspeak community. The VM is the > one place where we can continue to work together for the benefit of all > three communities. We should not, if at all possible, diverge, lest we > lose > some excellent contributions from some really terrific people, in one or > another community. > > All the best, > Ron Teitelbaum > > > If you skim over the diffs on Github [1], you will probably find that > most > of the > > changes are necessary to adopt Pharo-specific API changes. > > Not sure what the best way forward would be to avoid having the two > Squeak > > and Pharo flavors diverge even more. > > > > I am open to suggestions, don't have a good idea how to properly > 'modularize' > > these differences myself. > > > > Best regards > > Stefan > > > > [1] https://github.com/pharo-project/pharo-vm/pull/18 > > > > -- > > Stefan Marr > > INRIA Lille - Nord Europe > > http://stefan-marr.de/research/ > > > > > > > > > > > >

Feb. 13, 2014

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

by Stefan Marr

Hi Ron: On 13 Feb 2014, at 10:38, Ron Teitelbaum <Ron(a)USMedRec.com> wrote: >> I think the bigger question is whether you actually want to adopt those > things. > > That the vm stays in sync should be a core requirement for our communities. I am with you on that Ron. But I need a technical solution to manage those things. Good intensions are one thing, but how do we do that? Examples: [https://github.com/pharo-project/pharo-vm/pull/18/commits] primitiveUpdateGZipCrc32 - self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: GZipWriteStream crcTable]. + self cCode:â' inSmalltalk:[zipCrcTable := CArrayAccessor on: CRC crc32Table]. primitiveGetAttribute - attribute := Smalltalk getSystemAttribute: attr. + attribute := Smalltalk vm getSystemAttribute: attr. CogVMSimulator>> initialize - 'Display has not yet been installed' asDisplayText form. + 'Display has not yet been installed' asMorph imageForm. ioRelinquishProcessorForMicroseconds - Processor activeProcess == Project uiProcess ifTrue: + Processor activeProcess == UIManager default uiProcess ifTrue: And so far, I only fixed trivial things. Still need to figure out what is going wrong with more recent Pharo images. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

Feb. 13, 2014

Re: [Pharo-dev] [Vm-dev] Simulator in Pharo 3

by Ron Teitelbaum

> Stefan Marr > > Hi Eliot: > > On 13 Feb 2014, at 05:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Hmm. What's the easiest way to map this to a Monticello mcz so I can > integrate your changes back into my packages? > > I think the bigger question is whether you actually want to adopt those things. That the vm says in sync should be a core requirement for our communities. I realize that there is a split. There are some really great advancements going on in pharo-vm including new build methods and configurations. All of that has value if pharo can stay in sync with COG developments. It doesn't make sense to require Pharo developers to redo Eliot's work or to eliminate Pharo VM advancements from the Squeak / Newspeak community. The VM is the one place where we can continue to work together for the benefit of all three communities. We should not, if at all possible, diverge, lest we lose some excellent contributions from some really terrific people, in one or another community. All the best, Ron Teitelbaum > If you skim over the diffs on Github [1], you will probably find that most of the > changes are necessary to adopt Pharo-specific API changes. > Not sure what the best way forward would be to avoid having the two Squeak > and Pharo flavors diverge even more. > > I am open to suggestions, don't have a good idea how to properly 'modularize' > these differences myself. > > Best regards > Stefan > > [1] https://github.com/pharo-project/pharo-vm/pull/18 > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > > > >

Feb. 13, 2014

CI maintenance

by Christophe Demarey

Hi all, The build farm we use for continuous integration is powered by CloudStack. The version currently running is CloudStack 3.0. We will upgrade to CloudStack 4.2, a version supported by the apache community and fixing a lot of bugs. We hope to have a more reliable cloud with this upgrade. It will also allow, in a closed future, a storage extension (almost full at this time). This upgrade will have impacts on the service but we hope that they will be very short. At the end of the morning/beginning of the afternoon, you may notice: ci.inria.fr downtime (need to reboot some servers) cloudstack portal downtime (upgrade) maybe we will need to restart slaves after the upgrade. To summarize, the CI platform (jenkins, slaves) should be available as usual but there may be some downtimes. Thank you for your understanding, Christophe.

Feb. 13, 2014