- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PostID success story video

by btc＠openinworld.com

Feb. 13, 2014

Re: [Pharo-dev] [gsoc-mentors] GSoC: call for ideas

by Usman Bhatti

Project idea Description: Web Exporter for Roassal Skill level: intermediate Name of the mentor: Alex Bergel, Usman Bhatti, Description: Roassal is an agile visualization engine. It is made to visualize and interact with any arbitrary data, defined in terms of objects and their relationships. Graph-ET [1] is a project to draw charts and it is built on top of Roassal. With the web becoming omnipresent, It is desirable to export Roassal visualizations into html so that these visualizations/charts can be embedded into web pages. Both Roassal and GraphEt will benefit from the exporter. All Roassal visualizations will work out-of-the-box in the desktop and web mode without needing the code to be ported on Amber [2]. [1] http://gsoc2013.esug.org/projects#h-19 [2] http://gsoc2013.esug.org/projects/roassal-in-amber On Tue, Feb 11, 2014 at 10:42 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > Hi fellow Pharo hackers, > > ESUG, the European Smalltalk User Group, is applying for this > year's Google Summer of Code. As you probably know, the Summer > of Code provides the opportunity to fund students to work during > the summer on Pharo. Please reply to this > email (be sure to use "Reply to all") if you have ideas you > would like to propose. > > Please include a summary of the project and links to web pages > that can help prospective students to write their application. > Please also include the following information: > > - if applicable, other dialects that you would be willing to > mentor this project for > > - the skill level > > - name of the mentor(s), email addresses, and possibly any IRC > network/channel/nickname where they can be found. > > Thanks for contributing to ESUG's Summer of Code application! > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > > -- > You received this message because you are subscribed to the Google Groups > "Smalltalk GSoC mentors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to smalltalk-gsoc-mentors+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

Feb. 13, 2014

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

by J. Vuletich (mail lists)

Hi Folks, (below) Quoting Stefan Marr <smalltalk(a)stefan-marr.de>: > 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/ All these can be handled without much trouble in a new package "VMMaker compatibility for Pharo" or such. Cheers, Juan Vuletich

Feb. 13, 2014

Re: [Pharo-dev] SqueakSSL fixes

by GÃ¶ran Krampe

Hi guys! Ok, soo.... obviously I now noted these files didn't include the latest tweaks from Levente (mem leaks) etc. Just a heads up. Let's now move this thread to vm-dev only - don't want to spam squeak-dev nor pharo-dev. I presume people interested track vm-dev. So if you reply - stick to vm-dev. :) regards, GÃ¶ran

Feb. 13, 2014

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