April 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] NBOpenGL update
by Igor Stasenko Jan. 6, 2013

Jan. 6, 2013

Hi there, for those, who interested, i updated a NBOpenGL configuration. Changes are: - updated GL API to most recent available (taken directly from opengl specs). Now there is about 300 more methods to explore :) - finally dealt with win32 support code and made it working again - fixed the GLX function prefix , which should be 'glX' not 'glx' To load it in 1.4 use: Gofer new squeaksource: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load. and then (ConfigurationOfNBOpenGL project version: '1.0.2') load I did not tested the update thoroughly.. so i would appreciate if people will try it out and tell how it goes. -- Best regards, Igor Stasenko.

7 13

[Pharo-project] GSoC: ARM jitter for Squeak VM
by Nick Ager Nov. 27, 2012

Nov. 27, 2012

Here's hoping that in a similar way to Yanni and the ePUB proposal and someone will jump in and say that they are already working on this. Quoting Eliot: It's not overambitious for someone good. And I'd love to see it happen. > But finding time to be a mentor has proven difficult for me in the past. > I'd happily be part-mentor, but I need someone to at least help in the > GSoC process... so if there is anyone out there that can help Eliot and Igor with mentoring or the GSoC process, jump in and offer support. The proposal: ----- Name: ARM jitter for Squeak VM Level: Advanced Possible mentor: Eliot Miranda Possible second mentor: Igor Stasenko Description The Squeak VM is the dynamic virtual machine used for many open-source software projects such as Scratch [1], eToys [2], Pharo [3], the Newspeak language [4], the innovative web framework Seaside [5] and many others. CogVM [6] is a development of the Squeak VM which adds a powerful Intel x86 JITer [7]. The CogVM JIT has significantly improved the performance of the open-source Smalltalk projects which have adapted to use it. Increasingly low cost highly capable ARM hardware such as the Raspberry Pi [8] and the Beagle Board [9] have become widely available. In addition the new version of the one-laptop-per-child is based on the ARM platform [10]. The Squeak VM compiles for ARM platforms, but currently there is no JIT on ARM platforms, significantly decreasing the performance of popular software on ARM. The goal of this project is to add simple ARM JITTing capability to the CogVM. [1] http://scratch.mit.edu/ [2] http://www.squeakland.org/about/intro/ [3] http://www.pharo-project.org [4] http://newspeaklanguage.org/ [5] http://seaside.st/ [6] http://gitorious.org/cogvm [7] http://en.wikipedia.org/wiki/Just-in-time_compilation [8] http://www.raspberrypi.org/ [9] http://beagleboard.org/bone [10] http://one.laptop.org/about/xo-3 Technical Details The work would require a interest in virtual machine optimisation, some knowledge of Intel x86 and ARM assembler and knowledge of C and dynamic languages. The Squeak and Cog VM are written in a simplified subset of Smalltalk known as slang [11] - which then generates C output and forms the basis of the VM. As the Squeak VM is a Smalltalk program, it is developed in Smalltalk, and the Cog JIT is no exception. The VM, including the JIT, is written in Smalltalk and run in the context of the Smalltalk IDE, but the JIT still generates machine-code that must be evaluated within the Smalltalk environment. On x86 is done by interfacing to an x86 simulator library derived from the Bochs x86/x86-64 PC simulator, written in C++. Implementing the ARM port should be no different. The first task will be to choose and interface to a suitable ARM simualtor/emulator. Once this is working, the ARM code generator can be incrementally developed within Smalltalk. Finally once the simulator is fully functional one can get down and dirty with an actual physical ARM machine - such as the Raspberry Pi or Beagle Board. [11] http://wiki.squeak.org/squeak/2267 Benefits to the Student The student will gain an in-depth knowledge of virtual machine optimisation, working in a productive innovative environment - it's great fun to be able to implement a JIT in a safe high-level dynamic language, instead of the traditional route of developing in C/C++ and debugging in GDB. The student will have the satisfaction of seeing performance gains for a range of high-profile projects which use the Squeak VM on ARM. Benefits to the Community The Smalltalk community will gain an initial implementation of an ARM Jitter which can then be further developed along-side the x86 dynamic translation work. An ARM Jitter for the CogVM will improve the performance of many notable open-source projects on low-cost ARM hardware, bringing innovative software and development environments to wider community. ---- Cheers Nick

10 13

[Pharo-project] [dropped by admin]
by StÃ©phane Ducasse Sept. 19, 2012

Sept. 19, 2012

[dropped by admin]

5 6

Re: [Pharo-project] How to resurrect an unrepsonsive image?
by Marcus Denker Sept. 18, 2012

Sept. 18, 2012

On Dec 8, 2011, at 9:24 PM, Benoit St-Jean wrote: > I'm sure he is but Dolphin being a great environment, I don't mind when people remind (or inform) others of great ideas in other Smalltalk environments... As a Smalltalker, I don't mind seeing references to VAST, VW, ObjectStudion or even VSE here when something great/elegant/clever can be learned/imported/inspired from those... > But in *every* email? This is like when you switch job and in *every* conversation you say "But in my old company we did X". So What? Or even when you are in another country to remind everyone that "in $MyHomeCountry this is better". Yes, even if you are right, after the 49th time it gets idiotic. Especially, if it's just *talk* and not *do*. Marcus -- Marcus Denker -- http://marcusdenker.de

3 3

[Pharo-project] Pharo in OpenShift
by garduino July 28, 2012

July 28, 2012

Hi People: I'm doing some efforts to make Pharo work in OpenShift (the cloud initiative of Red Hat) using the DIY (do it yourself) cartridge. I started trying with Swazoo, but looks like SwazooServer is ignoring the ip address specified and binding to all interfaces (0.0.0.0) (Was an advice of a RedHat engineer). Then tried with Zinc (thanks Sven by the off list help [1]) and seems to work now (Using #bindingAddress:). I need still to polish a ton of things (the code itself, that not always work ok reading the RedHat environment (I'm doing via OSProcess), also I need to discover some random issues opening the authorized port, and finally develop the automation scripts to start/stop/restart). But I'm happy because is proved that the cog vm 2540 + Pharo 1.4 with Zinc works ok in OpenShift, as you can see at: http://zinc-garduino.rhcloud.com/ When I have more progress I will comment and document, my goal is that Smalltalk get included as an option in OpenShift (as currently are php, python, java, ruby). We are not second class citizens :) I must also say a big thanks to several people of Red Hat because they have showed your interest in Pharo and helped me a lot. The interesting part of OpenShift is that in the Express version 1.5 GB RAM and 3 GB disk space are availables for free! Well, it's all for now, cheers! [1] Sven, the latest mcz published today of ZincHTTPComponents seems to have some issues with the newest method #bindingAddress: (I don't have time now, but will try to reproduce in the next days if you need). -- View this message in context: http://forum.world.st/Pharo-in-OpenShift-tp4560365p4560365.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 6

[Pharo-project] [update 1.2] #12339
by Marcus Denker July 25, 2012

July 25, 2012

12339 ----- Issue 3575: [Failing Tests] Obsolete classes after tests (workaround) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

4 4

[Pharo-project] FileSystem. Possible FSReference rename
by Denis Kudriashov July 12, 2012

July 12, 2012

Hello, I hear many people does not like name FSReference in FileSystem package. Me too. Its not clear to me. But it is main object for end user. Maybe we can rename it to FSLocation? I frequently name variables that point to some file/dir like imagesLocation, settingsLocation and others. Therefore it is natural to me have FSLocation instead FSReference. What do you think?

5 7

[Pharo-project] Where did the Promise go?
by Stefan Marr July 4, 2012

July 4, 2012

Hi: Was the Promise class removed from the system for cleaning, and because it was not used? Or was there another reason for not having it in its classic form? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

6 8

[Pharo-project] Help "migrating" from classic streams to XStreams
by Mariano Martinez Peck June 22, 2012

June 22, 2012

Hi guys. We are developing Fuel with Martin Dias. Fuel is a binary serializer similar to Parcels. More info in http://rmod.lille.inria.fr/web/pier/software/Fuel For the moment, we are using the "classic" streams we want to give it a try to XStreams. My knowledge on streams is very little, so if someone can give me a hint I would really appreciate it. What I want to do right now is an adaptor of XStreams to classic stream. I mean, I want to create custom subclasses of XTFileWriteStream and XTFileReadStream that implements the same API from classic streams that we use in Fuel. And the implementations of such methods will do just a "self something" where something is the way of doing that in XStreams. So, the following is the protocol we use in Fuel for streams, and what I would love to know is the associated way to do it it XStreams. The left is classic streams, and after the "->" it is XStreams: *Reading:* nextNumber: -> ?? nextPutAll: -> write: nextStringPut: -> ?? nextPut: -> put: nextNumber:put: -> ?? nextWordPut: -> ?? *Writing: * nextNumber: -> ?? next: -> read: nextString -> ?? next -> get nextWord -> ?? Thanks a lot in advance, -- Mariano http://marianopeck.wordpress.com

3 6

[Pharo-project] Refactoring Questions
by Camillo Bruni May 28, 2012

May 28, 2012

after having a look with ben at the current refactoring implementation in Nautilus we found that the "Extract into temporary" refactoring is most of the time not that useful. I wonder wether it would make sense to loosen the requirements on conserving behavior... consider the following example where we extract "self foo" into the temporary "tmp": =========================================== foo ^ self foo even ifTrue: [ self foo * 2 ] ifFalse: [ self foo / 2 ] actual result ============================= foo | tmp | tmp := self foo. ^ tmp even ifTrue: [ self foo * 2 ] ifFalse: [ self foo / 2 ] proposed result =========================== foo | tmp | tmp := self foo. ^ tmp even ifTrue: [ tmp * 2 ] ifFalse: [ tmp / 2 ] =========================================== note that the proposed solution is not side-effect free. However the given refactoring hardly makes ever sense, since this action can be easily done manually in less time. given that you first have to find the proper menu-item. best cami

3 2