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

What is wrong with Settings Browser ?

by jannik laval

Hi pharoers, I have a small problem with Settings Browser: when I open it on a single package settings, it is really slow. Just try it. Opening a Settings browser is fast (213ms on my machine): == SettingBrowser new open == Now, with a specific package name, it is really slow (5284ms on my machine !!!): == SettingBrowser new setViewedPackageNames: 'Settings-Network'; open. == or this line: == SettingBrowser new changePackageSet: {PackageOrganizer default packageNamed: 'Settings-Network' ifAbsent:[]}; open. == I don't understand what is wrong. Any idea ? Cheers, -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/

Feb. 13, 2014

Google Encourages Developers to Create Art Using Code

by Eliot Miranda

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

Feb. 13, 2014

Re: [Pharo-dev] need some help with NBCallback related crashes

by Eliot Miranda

cc'ing vm-dev cuz /this is a vm-dev issue/. On Wed, Feb 12, 2014 at 4:40 AM, Danil Osipchuk <danil.osipchuk(a)gmail.com>wrote: > 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. > There is a leak checker in the VM that you can use. Use -leakcheck 3 to run the leak checker before each full GC (1) and incremental GC (2, 1 + 2 = 3). Use -leakcheck 7 to run it before each become as well. This should at least print an error before the crash. If you then use gdb to stop in the warning function you can use facilities such as printOop to find out which object is crapping out. HTH and please bring issues like this up on vm-dev. > > > 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) > > -- best, Eliot

Feb. 13, 2014

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

by Luc Fabresse

this is really nice. good job JB! I should try it. #Luc 2014-02-13 19:21 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Just a question: did you switch back to bitmap fonts? > > > 2014-02-13 19:01 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Very nice, I will try it over the weekend ! >> Thanks! >> >> On 13 Feb 2014, at 18:38, Jean Baptiste Arnaud < >> jbaptiste.arnaud(a)gmail.com> wrote: >> >> > Small picture for you: >> > >> > <photo.jpeg> >> > On 13 Feb 2014, at 18:27, Jean Baptiste Arnaud < >> jbaptiste.arnaud(a)gmail.com> wrote: >> >> >> >

Feb. 13, 2014

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

by Ronie Salgado

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 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 >

Feb. 13, 2014

Re: [Pharo-dev] Versionner Suggestions

by Benjamin

On 13 Feb 2014, at 19:51, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > 12877 Versionner: Make Project Editing More Prominent > https://pharo.fogbugz.com/default.asp?12877 > It wasn't immediately obvious to me that I had to double click on a project > to edit the configuration. Maybe we should add a button? At minimum, it > should be added to the context menuâ¦ I made the exact same suggestion to Christophe this afternoon :) Ben

Feb. 13, 2014

Re: [Pharo-dev] [Pharo-users] Slides for "Pharo: A Reflective System"

by Sven Van Caekenberghe

On 13 Feb 2014, at 17:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 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 Very nice: deceptively simple, yet powerful. Thanks for doing all this: we can all learn from this. Sven

Feb. 13, 2014

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

by Sven Van Caekenberghe

On 13 Feb 2014, at 19:55, btc(a)openinworld.com wrote: > Sean P. DeNigris wrote: >> 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. >> >> >> >> > Zinc is what I had in mind. This is something I might work on outside of work time, to have utility "ready" for next time. > However to learn the new things I needed to develop it would take longer than that one hour of work time. > And you know the truth about automation... > https://xkcd.com/1319/ Hahaha, yes these are always very funny. Zinc and HTTP are pretty easy to learn: http://zn.stfx.eu/zn/zinc-http-components-paper.html http://zn.stfx.eu/zn/zn-talk-pharo-conference.pdf http://zn.stfx.eu/zn/build-and-deploy-1st-webapp These should get you started, the rest is just learning more about HTTP from anywhere, combined with classic Smalltalk exploration. Regards, Sven

Feb. 13, 2014

Re: [Pharo-dev] PostID success story video

by btc＠openinworld.com

Feb. 13, 2014

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

by btc＠openinworld.com

Feb. 13, 2014