- Pharo-dev - lists.pharo.org

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

by Eliot Miranda

On Thu, Feb 13, 2014 at 6:19 AM, <btc(a)openinworld.com> wrote: > phil(a)highoctane.be wrote: > >> 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 >> >> Getting the simulator working in Pharo could be a GSoC project? or is it > too advanced? > If you guys would read and contribute to vm-dev you'd already know that someone with no VM experience (tty) just implemented event processing for the simulator window. The simulator only supported the old polling event architecture. So no it's not too advanced. But more importantly why aren't you all discussing vm stuff on the vm forum? > cheers -ben > -- best, Eliot

Feb. 13, 2014

Re: [Pharo-dev] ARM, Raspbian: Good new everyone, Raspbian display is now fixed

by Jean Baptiste Arnaud

Small picture for you: On 13 Feb 2014, at 18:27, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote:

Feb. 13, 2014

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

by Eliot Miranda

On Thu, Feb 13, 2014 at 2: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? > I would implement isPharo/isSqueak/isNewspeak in VMClass. These can answer e.g. the value of a class variable. hence, below... > 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]. > primitiveUpdateGZipCrc32 self cCode:'' inSmalltalk:[zipCrcTable := CArrayAccessor on: (self isPharo ifTrue: [CRC] ifFalse: [GZipWriteStream]) crcTable]. > > primitiveGetAttribute > > - attribute := Smalltalk getSystemAttribute: attr. > + attribute := Smalltalk vm getSystemAttribute: attr. > This is just my code base being a little out of date. Smalltalk vm getSystemAttribute: works in Squeak. I'll update my code. > CogVMSimulator>> initialize > - 'Display has not yet been installed' asDisplayText form. > + 'Display has not yet been installed' asMorph imageForm. > This needs to be isPharo. > > > ioRelinquishProcessorForMicroseconds > - Processor activeProcess == Project uiProcess ifTrue: > + Processor activeProcess == UIManager default uiProcess ifTrue: > Ditto, until Squeak changes? > > > And so far, I only fixed trivial things. Still need to figure out what is > going wrong with more recent Pharo images. > But fab that the simulator is receiving attention on Pharo (and Tty's work with events is great too). Now if there could be an automatic job to export whatever git state is the current official Pharo VM to a Monticello VMMaker package I'll be very much happier. Also for this discussion should we continue to cross-post or is vm-dev an adequate forum? Answers from Pharoites please... I have to admit that I'm a bit troubled by how often subjects that are clearly vm-centric are raised on pharo-dev. To Pharoites perceive vm-dev as a squeak thing? If so, may I suggest pharo-vm-dev? If not, can the Pharo community make an effort to direct vm discussion towards vm-dev in future? > Best regards > Stefan > > -- > Stefan Marr > INRIA Lille - Nord Europe > http://stefan-marr.de/research/ > -- best, Eliot

Feb. 13, 2014

Re: [Pharo-dev] ARM, Raspbian: Good new everyone, Raspbian display is now fixed

by Jean Baptiste Arnaud

In addition all the semaphore should work well now for Raspbian. On 13 Feb 2014, at 17:38, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > Hello > I finally successfully fixed the PharoS bug on Raspbian. > So now the UI is not completely block it is just slow. > > As it is not yet merge with the common Pharo repository (the pull request is send), but you can test it here: > https://ci.inria.fr/pharo-contribution/view/RaspberryPi-Experimentation/job… > > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Feb. 13, 2014

Re: [Pharo-dev] Killer applications (or small killer utilities)

by Torsten Bergmann

> So I throw out the question.... What "small" end-user utilities do you > think Pharo could perform well at? Several ideas for possible killer-apps/possible killer-utilities come to my mind. One I like most: <my_idea> Build a refactoring tool for databases to refactor and cleanup schemas and data. ("Database refactoring browser"). Including visualizations, undo functionality and Smalltalk as scripting language to easily apply changes to data or the schema. So a developer, a DB admin or business user can first try changes on data/schema on a copy of the original database and when they fit later replay the changes/scripts on the original production database. Also easy visualizations of contained data is important. Even business users (without SQL knowledge) should be able to visualize, create reports or change data. As Smalltalk is closer to english and its explorative nature it could be a real enabler for such a tool as the built in scripting language. DabbleDB has shown that a tool written in Smalltalk mixed with data and applied meta infos could easily provide business value and make data more usable. Technology tends to change from time to time in companies - but accessing and maintaining the data is key... </my_idea> Too much work for a single person, but if anyone is interested tell me. Bye T.

Feb. 13, 2014

ARM, Raspbian: Good new everyone, Raspbian display is now fixed

by Jean Baptiste Arnaud

Hello I finally successfully fixed the PharoS bug on Raspbian. So now the UI is not completely block it is just slow. As it is not yet merge with the common Pharo repository (the pull request is send), but you can test it here: https://ci.inria.fr/pharo-contribution/view/RaspberryPi-Experimentation/job… Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

Feb. 13, 2014

Slides for "Pharo: A Reflective System"

by Marcus Denker

Hi, Somehow I got myself into giving a 30min âcoffee breakâ talk here at the lab. Pharo: A Reflective System http://www.slideshare.net/MarcusDenker/pharo-a-reflective-system http://marcusdenker.de/talks/14Inria30MinScience/PharoAReflectiveSystem.pdf Nothing new, of courseâ¦ but it was not that easy to do a 30minute talk about that, I have to say. (But seemingly it worked). Marcus

Feb. 13, 2014

Re: [Pharo-dev] Killer applications (or small killer utilities)

by Sean P. DeNigris

btc wrote > As I spent the hour doing this manually one at a time Why not use Zinc + Soup? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Why-Smalltalk-is-not-popular-tp4743009p4743336.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 13, 2014

Re: [Pharo-dev] [OT] Speed of light 6-2-2014

by Chris Muller

I totally agreed with "Apple is a product-driven company, not a computing-driven company." But part of the irony of his post occurs between his first and last statements: First statement: "When most programmers are introduced to Objective C for the first time, they often recoil in some degree of disgust at its syntax: âSquare brackets? Colons in statements? Yuck" Last statement: "It seems absurd beautiful graphical applications are created solely and sorely in textual, coded languages." How much of the close-mindedness reflected by the 1st statement do you suppose causes results described by his last statement? Because if developers are so fickle they can't even get to a superficial improvement in _syntax_, they cannot open their minds to new ideas, hence they stuck in the same ideas for 30 years. On Wed, Feb 12, 2014 at 5:02 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > some quotes: > > > "Borrowed largely (or shamelessly copied) from Smalltalkâs message sending syntax ..." > > "Categories or through runtime functions (more on those soon) itself, but Objective Câs objects pale in comparison to those of a Smalltalk-like environment, where objects are always live and browsable" > > "So if a successor language is to emerge, itâs got to come from elsewhere." > > "It seems absurd that 30 years after the Mac we still build the same applications the same ways. It seems absurd we still havenât really caught up to Smalltalk. It seems absurd beautiful graphical applications are created solely and sorely in textual, coded languages. And it seems absurd to rely on one vendor to do something about it." > > see > > http://nearthespeedoflight.com/article/2014_02_06_objective_c_is_a_bad_lang… >

Feb. 13, 2014

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

by Frank Shearar

On 13 February 2014 15:21, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Project idea > > Description: Enhance refactorings with type information > Skill level: Advance > Possible Mentors: Guillermo Polito / Esteban Lorenzano / Santiago Bragagnolo > Name of the Student: Pablo Tesone > Keywords: tools, refactoring, code completion, type inference. > > Description: > > During the development of a program in any programming language, the IDE has > a very important role. It will never replace the knowledge of the programmer > but it can make his life easier. > As Smalltalk doesnât have explicit type information, the IDE can not perform > the same mechanisms that are present in IDE like Eclipse or Intellij IDEA. > These mechanisms can be very useful. > The idea of this project is to add type inference mechanisms to try to > provide more information to the refactoring and code completion tools. > It is important to say that the idea is not to check types or correct the > program, but to allow the programmer to have more information. Mainly this project sounds like _using the existing inference tools_ (RoelTyper, Francisco Garau's Concrete Type Inference with Santiago Bragagnolo's modifications/improvements of same) and exposing the information in the IDE, yes? (This is a very important step!) frank

Feb. 13, 2014