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

Jenkins build became unstable: Pharo-2.0-Tests Â» run 1,vm,linux #283
by no-reply＠ci.inria.fr Feb. 14, 2014

Feb. 14, 2014

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=linux…>

1 0

Google Encourages Developers to Create Art Using Code
by Eliot Miranda Feb. 14, 2014

Feb. 14, 2014

http://www.eweek.com/developer/google-encourages-developers-to-create-art-u… -- best, Eliot

3 3

Re: [Pharo-dev] [Pharo-users] [gsoc-mentors] GSoC: call for ideas
by Ronie Salgado Feb. 13, 2014

Feb. 13, 2014

Hi Eliot, We were having some discussions about those topics, with Esteban Lorenzano and Stephane Ducasse. Esteban was the one who told me about callbacks, so I wrote according to what I remembered about that. About portability, only x86 ia32 is supported, with some stubs for ARM and PPC in the old FFI. In Pharo, only NativeBoost FFI is actually supported, at least in the official releases, in there end-user friendly callbacks are not supported. The main problem with adding those implementations is lack of good documentations. The C files of the old FFIs are poorly written, they have lots of #ifdef/#endif which makes reading their code really hard, except for the person who wrote them. Those C files should have a clear defined external interface and proper separations for architecture and operating systems. That is a problem because nobody wants to touch that code. About LLVM, this is only for FFI when you don't have a NativeBoost implementation for your platform, but there is already a LLVM JIT implemented, for example x86 ia32 and AMD64, ARM, probably PPC. You cannot compare our workforce with the one in LLVM and I think is a better idea to use it as a fallback for when we have nothing and then be able to add something better. For fast FFI you only have to create a C function that performs all the marshalling from the Smalltalk objects into the receiver C function types, then perform the actual C function call. That is the way that NativeBoost works, and it can be done by using LLVM, or even your favorite C compiler. So, about the bloating and dependency, I completely agree with you, but we need at least an interpreter based VM for x86 AMD64, ARM, PPC, and maybe some other popular/future platforms that supports communication with C. In fact, I am not interested in the LLVM optimizer, and probably I am not going to use it. I also know about the efforts on the virtual CPU, and I think that is the correct approach. The problem is how much time is going to take to complete for all the platforms, integrate it into NativeBoost and deploy it in the VM, with maybe at most two person at time working on them. In platforms, such as iOS you cannot use JIT at all, so you have to either use an interpreter or AOT everything and static link every dependency, that is where the static "fake FFI" enters into scene. BTW, end-user consumer applications in lot of platforms when deployed don't need or cannot have the full live coding system, debugger and browser, so losing a bit of flexibility here is not a problem. On January with Igor, we started making a direct graphics API, named OSWindow and we tossed all the vm-display code for Linux. If we continue with that work, FFI is going to become a core feature required to be able to make the main operating system Pharo window. So, if we don't have some portable way of doing FFI things in Pharo, being able to port it is going to become a lot more difficult. Greetings, Ronie Salgado 2014-02-13 17:22 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Ronie, > > > On Thu, Feb 13, 2014 at 11:47 AM, Ronie Salgado <roniesalg(a)gmail.com>wrote: > >> I am proposing the following as a student: >> >> Project idea >> >> Name: Unified Foreign Function Interface >> Skill level: Advanced >> Possible Mentors: Igor Stasenko / Esteban Lorenzano >> Name of the Student: Ronie Salgado >> >> Description: >> >> Because NativeBoost has problems with portability and cannot be used >> anywhere(iOS), one proposal is making a modular unified foreign function >> interface. This UFFI should support multiples backends, a portable function >> calls specification, portable easy to use callbacks support, and portable >> foreign resources management. >> >> Full Description Document: >> http://users.dcc.uchile.cl/~rsalgado/uffi-fourth-draft.pdf >> > > This is interesting but I take issue with a couple of things. First of all > > "The old Squeak FFI has problems with portability, callbacks and > speed." > > I disagree that there are problems with callbacks. In fact, IIRC the > only callback facility we have is that which I implemented which is used > both by Alien and FFI and works well enough that the Newspeak system used > it to implement a native GUI on windows where callbacks are used to receive > Windows events. That counts as working in my book. Also, the architecture > I implemented is portable to other ABIs than x86. > > But my major objection is to this: > > "One interesting idea is to make a backend that uses LLVM compiler > infrastruc- ture, because it is designed for compiling optimized C function > and it already has multiples JIT backends. This small project is not to > make a full Pharo VM JIT based in LLVM, because LLVM is not designed for > that and it would require a lot of patching of LLVM." > > IMO that's a very poor choice. LLVM is large, having a footprint of about > a couple of megabytes. The Cog JIT is in contrast about 330k at its > largest (Newspeak, support for two instruction sets, plus primitives, plus > GC interface, etc, etc). If we as a community put effort into extending > this we'll have a smaller footprint, a better JIT, and less dependencies. > There's insignificant opportunity for using LLVM's optimizer when > engineering call-outs and call-backs; they're too simple. So there's > nothing to be gained other than bloat and dependency. And not putting > effort into our own infrastructure is IMO a very bad idea. > > Note the synergy with ClÃ©ment and my work on speculative inlining which > will extend the Cog JIT. > > 2014-02-13 12:21 GMT-03:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: >> >> 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. >>> >>> >>> >>> On Thu, Feb 13, 2014 at 12:06 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: >>> >>>> [Anne Etien could not post this msg on the mentors list I m forwarding >>>> it on her behalf]. >>>> >>>> Title: FAST JavaScript model >>>> >>>> Level: advanced >>>> >>>> Possible mentor: Anne Etien >>>> >>>> Possible second mentor: Nicolas Anquetil or Yuriy Tymchuk >>>> >>>> Description: >>>> For in depth source code analysis a support of abstract syntax trees is >>>> required. FAST is an abstract syntax tree extension for FAMIX meta-model >>>> that is used by Moose technology. The goal of this project is to create >>>> a JavaScript version of FAST. >>>> >>>> Technical Details: >>>> As programming languages are different, their AST representations are >>>> different too. FAST model aims for creation of as generic as possible >>>> core that can be extended for different languages. Also the structure of >>>> a model allows creation of generic algorithms like symbol resolution, >>>> metrics calculation and rule checking that will work for any language. >>>> Prototypes of FAST for Smalltalk and Java are already implemented. >>>> During the project a student will implement the JavaScript model. More >>>> detailed information about FAST is provided in the Moose day >>>> presentation: http://youtu.be/dRr3WHOD3x4 >>>> >>>> Benefits to the Student: >>>> The student will gain a deep understanding of a JavaScript syntax and >>>> abstract syntax tree model. He will also learn about PetitParser >>>> framework, and gain knowledge about software modeling and analysis. >>>> >>>> Benefits to the Community: >>>> Community will get a FAST model for JavaScript that can be used for >>>> software assessment with Moose. Also this model can be used later in PhD >>>> projects such as automation of source code translation. With this third >>>> model, the community will have raw material to real think and improve >>>> generic algorithms based on AST. >>>> >>>> >>>> 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. >>>>> >>>> >>>> -- >>>> 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. >>>> >>> >>> >>> >>> -- >>> Pablo Tesone. >>> tesonep(a)gmail.com >>> >> >> > > > -- > best, > Eliot >

1 0

Why Smalltalk is not popular?
by askoh Feb. 13, 2014

Feb. 13, 2014

The recent arguments in Smalltalk made me have an Eureka moment on why Smalltalk is not popular. Smalltalk attracts brilliant people. But these brilliant people scare others away. Instead of Showing How, they Show Off. Instead of being inclusive, they are picky. Instead of discussing, they fight. So, Smalltalkers, please be humble, friendly and pacific. Show How. Invite anyone interested to join. And let's talk normally. All the best, Aik-Siong Koh -- View this message in context: http://forum.world.st/Why-Smalltalk-is-not-popular-tp4743009.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

14 23

need some help with NBCallback related crashes
by Danil Osipchuk Feb. 13, 2014

Feb. 13, 2014

Hello all I'm currently playing with NativeBoost (a great thing to have) and pharo consistently crashes after running for a while. My impression is that crashes happen during GCs as if something moves under the installed callback. This may be also related to the libpcap itself, but how can I know for sure. I've tried everything newest (vm+image+libpcap) and I also migrated into a much more rigid scheme of storing and passing callback. Now I've run of ideas where to look further. So, it is like this. NBPCapHandlerCallback is a procedure which is called by libpcap for every packet it has in its internal buffer after the application calls pcap_dispatch(). pcap_dispatch receives the callback as a parameter. I have to repeatedly call pcap_dispatch in so called nonblocking mode (and pass the callback each time) every 5 milliseconds to collect packets - we are single threaded. This amounts to awful whole 200 callback installations per second, may be libpcap was not well tested in this scenario (I suppose pcap_loop runs in separated thread in wireshark and callback installation happens several times per session at most) - hence my doubts. But also - could it be something with NB? Any hints how to proceed with it are greatly appreciated. This is amazing how one can quickly assemble something that emulates thousands of dhcp-clients (this is what the app does) with current Pharo. But the thing dies off after 10-15 minutes. best wishes, Danil http://www.tcpdump.org/manpages/pcap_loop.3pcap.html ========= Generic failure NBNativeCodeGen class>>signalError: NBNativeCodeGen class>>handleFailureIn:nativeCode: NBNativeCodeGen class>>methodAssembly: LargePositiveInteger(NBFFICallback)>>primLeave:stackPtr:contextOop:returnValue:primitiveMethod: NBPCapHandlerCallback(NBFFICallback)>>pvtEnter:stackPointer:primitiveMethod: in Block: Segmentation fault Wed Feb 12 16:17:25 2014 pharo VM version: 3.9-7 #1 Fri Feb 7 16:55:52 CET 2014 gcc 4.6.3 [Production ITHB VM] Built from: NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Feb 7 2014 With: NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Feb 7 2014 Revision: https://github.com/pharo-project/pharo-vm.git Commit: ef5832e6f70e5b24e8b9b1f4b8509a62b6c88040 Date: 2014-01-26 15:34:28 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14797 Build host: Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux plugin path: /home/Pharo/ [default: /home/Pharo/] C stack backtrace: ./pharo[0x809bc4c] ./pharo[0x809bf66] linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xb76e640c] ./pharo(incrementalGC+0x18a)[0x80859da] ./pharo[0x808655a] ./pharo[0x808cbb7] ./pharo[0x808ccba] ./pharo(ceStackOverflow+0x59)[0x808f5f9] [0x770f5260] [0x771017e0] [0x770fb11e] [0x770fa939] [0x770f9813] [0x770f5700] [0x770f55c0] Smalltalk stack dump: 0xbf8b6144 M BlockClosure>ensure: 0x7c429d44: a(n) BlockClosure 0xbf8b6164 M Semaphore>critical: 0x772901d8: a(n) Semaphore 0xbf8b6180 M SmallInteger(Integer)>atRandom 0x13=9 0xbf8b61a8 M NLDHCPClientInit>enter 0x7c3be76c: a(n) NLDHCPClientInit 0xbf8b61c0 M [] in NLDHCPHost>changeStateTo: 0x793e816c: a(n) NLDHCPHost 0xbf8b61e0 I [] in BlockClosure>newProcess 0x7c3be828: a(n) BlockClosure Most recent primitives at:put: at:put: at:put: at:put: basicNew: basicNew class class replaceFrom:to:with:startingAt: basicNew: basicNew class class replaceFrom:to:with:startingAt: species species at:put: at:put: class class replaceFrom:to:with:startingAt: species species at:put: at:put: class class replaceFrom:to:with:startingAt: at:put: species basicNew: replaceFrom:to:with:startingAt: class class species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: basicNew: atAllPut: class class replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: at:put: at:put: class at:put: at:put: at:put: species basicNew: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: basicNew: basicNew class class replaceFrom:to:with:startingAt: class class species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: basicNew: basicNew class class replaceFrom:to:with:startingAt: class class replaceFrom:to:with:startingAt: class class replaceFrom:to:with:startingAt: basicNew: at:put: at:put: class class replaceFrom:to:with:startingAt: class class replaceFrom:to:with:startingAt: class class replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: new at:put: at:put: class stringHash:initialHash: class stringHash:initialHash: class stringHash:initialHash: basicNew objectAt: basicNew: stackp: basicNew primitiveResume basicNew basicNew new: basicNew new: objectAt: basicNew: stackp: basicNew primitiveResume findNextUnwindContextUpTo: terminateTo: suspend species basicNew: replaceFrom:to:with:startingAt: species species class class basicNew shallowCopy shallowCopy basicNew: basicNew species basicNew: replaceFrom:to:with:startingAt: class class replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: basicNew: basicNew species basicNew: replaceFrom:to:with:startingAt: class class replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: wait truncated truncated signal at:put: at:put: at:put: at:put: at:put: at:put: new at:put: at:put: class at:put: at:put: class stringHash:initialHash: class stringHash:initialHash: class stringHash:initialHash: class stringHash:initialHash: class stringHash:initialHash: class stringHash:initialHash: species basicNew: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: class species hashBytes:startingWith: species species class class class stringHash:initialHash: class stringHash:initialHash: class stringHash:initialHash: basicNew: basicNew class class replaceFrom:to:with:startingAt: basicNew: basicNew class class replaceFrom:to:with:startingAt: class class species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: class class species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: species basicNew: replaceFrom:to:with:startingAt: pcapSendPacket:size: findNextUnwindContextUpTo: terminateTo: suspend basicNew basicNew wait **IncrementalGC** stack page bytes 4096 available headroom 3300 minimum unused headroom 3480 (Segmentation fault)

2 1

Slides for "Pharo: A Reflective System"
by Marcus Denker Feb. 13, 2014

Feb. 13, 2014

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

2 1

PostID success story video
by Torsten Bergmann Feb. 13, 2014

Feb. 13, 2014

Anyone able to add the "PostID Software Development Toolkit" (created using Pharo at Pinesoft) http://www.youtube.com/watch?v=Izg_Dr2Cg7k&feature=youtu.be to the success story page at http://www.pharo-project.org/about/success-stories

4 4

Simulator in Pharo 3
by Stefan Marr Feb. 13, 2014

Feb. 13, 2014

Hi: Below you see the result of today, the simulator for the StackInterpreter running in a Pharo 3 image. Over the last years, people have been tinkering with the simulator from time to time, but I have the feeling everyone gave up before the thing was fully functioning, and not even the trivial things have found their way back into the VM code base. I am aware that Phil was busy with it recently, but I think there was also someone else posting notes here. Would be great if those people could send me their change sets so that I can try getting everything working again. As you can see in the screenshot, the simulator loads up properly, and executes the first 10,000,000 bytecodes. Which is enough to make it notice that a primitive fails, and to pop up the error dialog. However, it is a Pharo 1.2 image. Later images trigger some bug, I havenât identified yet. They execute code, but donât manage to bring up the display. Thanks to having a unified code repository, everything I got so far (minus a few small changes) is here: https://github.com/smarr/pharo-vm/tree/fixes/simulator-bit-rot More to come soon. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

8 18

dbxtalk working on pharo 3.0
by Tudor Girba Feb. 13, 2014

Feb. 13, 2014

Hi, I just retried DBXTalk, and it now magically works! Does anyone know why? :) I did this: Gofer new smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; package: 'ConfigurationOfOpenDBXDriver'; load. #ConfigurationOfOpenDBXDriver asClass loadBleedingEdge. Anyway, the only glitch I found is that the OpenDBX current wrongly returns "NBPharoOpenDBX class" instead of the instance. I could not figure out where the initialization bug comes from, but I worked around it with: NBPharoOpenDBX installAsCurrent. I tested the functionality with an Oracle backend, and it just worked. Thanks! Doru -- www.tudorgirba.com "Every thing has its own flow"

2 1

CI maintenance
by Christophe Demarey Feb. 13, 2014

Feb. 13, 2014

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.

1 0