March 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)

by Ben Coman

On Mon, Feb 29, 2016 at 7:44 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 29/02/2016 00:32, Ben Coman a Ã©crit : >> >> On Sat, Feb 27, 2016 at 3:30 AM, Dimitris Chloupis >> <kilon.alios(a)gmail.com> wrote: >>> >>> So now that AsmJit is gone , I had a new idea for a project and I wanted >>> your opinion on this if you think it will be useful for the community, I >>> call it WarpSpeed. >>> >>> I was thinking it would still be cool to have some kind of library that >>> will >>> help us boost the speed of pharo . So I was thinking about a C inliner >>> which is far easier than an Assembly inliner (see AsmJIT) I also found >>> TinyC >>> >>> http://bellard.org/tcc/ >>> >>> which is as you guessed a tiny c compiler 100kbs in size which i can >>> include with a pharo image to allow me to dynamically compile inlined C >>> code >>> inside the pharo image so even pharo users without a C compiler installed >>> can benefit from it . >>> >>> That means that if something does not perform as fast as you want you >>> could >>> mix C code with pharo code , I am thinking passing the C source code as a >>> string or even having the C code in a separate file, and then dynamically >>> call the TinyC compiler, compile it to shared library and load if via >>> UFFI >>> back to pharo. TinyC is very fast so compilation of the code should be as >>> fast if not faster than compiling pharo code. >>> >>> Looks easy enough to do for a small project by me with the condition >>> there >>> are people really interested into something like this. TinyC is licensed >>> as >>> LGPL but I can make it fall back to other compilers as well if ones want >>> to >>> close the source. >>> >>> How it sounds as an idea ? >> >> >> I've thought about something similar myself, and also looked at tcc. >> I think its a really interesting idea, but you need to treat it as an >> *experiment* for learning. Whether its ultimately useful to the >> community will depend on a lot of things in implementation (I see >> Clement indicates some difficulties). >> >> But maybe tcc is not the right backend. [1] says "Note: I am no longer >> working on TCC", the last release dates wehre 2009 & 2013, and [2] >> indicates it tcc may be a dead end. >> >> What would be *really* interesting is, given we have a good >> infrastructure to compile Smalltalk to bytecode, investigate some new >> constructs to compile to SPIR-V [3]. The specification [4] and >> execution/memory model [5] have recently been released. It would be >> nice if someone more competent than myself could skim and advise on >> the feasibility of such an idea. > > > SPIR-V format is similar to the LLVM-IR and it is quite hard to generate for > a language like Smalltalk. Typed operations, SSA, Phi nodes, etc... You get > extremely high performance this way, but it is a lot of work. > >> This presentation [6] starting p38 says SPIRV presents an "opportunity >> to unleash innovation: Domain Specific Languages..." which is >> typically considered a strength of Smalltalk. p40 says "Compiler split >> in two, Front end compiler emits SPIR-V portable binary offline (that >> would be us), then SPIR-V is compiled to machine-specific binary by >> driver online (that would be just passing the SPIR-V to the GPU >> driver). [7] > > > Yes, this is certainly where SPIR-V is interesting: all OpenCL devices would > carry a SPIR-V back-end compiler. > >> Perhaps interesting to see what people are trying in some other >> languages... >> * A bytecode translator like is being tried for Python [A], since SPIR-V >> is >> * End-user tools for working with SPIR-V, disassembling, analysing, >> debugging, optimising it, for Go[B] and Python[C]. >> >> The opportunity in producing tools for working with SPIR-V is you draw >> people in for the tool, and they get a side-exposure to our >> environment, (which of course they then fall in love with.) > The opportunity is more like a compiler infrastructure you'll be writing. If > well written, yes, it could be an interesting artefact (training, teaching > compilation). Back to Dimitris' original question, I wonder that the potential speed benefit comes not so much from using "C", but from leveraging a large body of work on optimizing passes at the lower level. I found a tutorial [1] to produce a toy language "Kaleidoscope" that generates LLVM IR such that "by the end of the tutorial, weâll have written a bit less than 1000 lines of code. With this small amount of code, weâll have built up a very reasonable compiler for a non-trivial language including a hand-written lexer, parser, AST, as well as code generation support with a JIT compiler." As well as a C++ version, there is also an OCaml version of the tutorial [2], which makes me wonder what a Pharo version of the tutorial would look like. This seems like a reasonable level for a student project. Know any students keen to try? [1] http://llvm.org/docs/tutorial/LangImpl1.html [2] http://llvm.org/docs/tutorial/index.html [3] http://llvm.org/docs/tutorial/PharoLangImpl1.html The project outline might be... 1. Implement Kaleidoscope via the existing C++ tutorial 2. In Pharo, write a minimal FFI interface to LLVM 3. Re-implement the Kaleidoscope tutorial in Pharo in its simplest form, following the existing tutorial's philosophy "to make this tutorial maximally understandable and hackable, we choose to implement everything in C++ instead of using lexer and parser generators" - matching the existing tutorial as close as possible to ease acceptance to... 4. Submit Pharo version of Kaleidoscope tutorial for inclusion on the LLVM site [3]. This would provide a showcase of Pharo to a group we'd probably never get a look in from**. In particularly where section 3.5 says "code generation to LLVM doesnât really get us much, except that we can look at the *pretty* IR calls" , we could demonstrate the ease of extending our Inspector with custom views, versus their textual presentation. 5. Revise the tutorial to make optimal use of our built in AST infrastructure. I naively wonder if it could be possible or beneficial for Slang to generate LLVM IR directly and cherry pick optimisation passes, with the ability to use in-image tools to review before & after transformation of each pass, rather than generating C first and only getting the final result. ** We operate in an attention scarcity economy. Saying "come and look at this great Thing we've got" is often not enough. It helps to be able to say "this Thung your interested in, here's another way to look at it (using Thing.)" Perhaps there's even an outside chance to snag passing interest from random LLVM guys in our Cog/Spur/Sista JIT technology. cheers -ben

March 2, 2016

Re: [Pharo-users] missing project from Pharo Catalog Browser

by Esteban Lorenzano

weirdâ¦ I will check the logs tomorrow (most probably a bug when reading baseline derived configurationsâ¦) Esteban > On 01 Mar 2016, at 22:48, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > I've noticed that my IconFactory is missing in both Catalog Browser and http://catalog.pharo.org/ <http://catalog.pharo.org/> > > Yet I can clearly see it in MetaRepoForPharo50, > > and the following also works (loaded from MetaRepo) > > Metacello new > configuration: 'IconFactory'; > smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo50'; > load > > Did I miss something? Because it used to be there and now its gone. > > Thanks, > Peter

March 1, 2016

missing project from Pharo Catalog Browser

by Peter UhnÃ¡k

Hi, I've noticed that my IconFactory is missing in both Catalog Browser and http://catalog.pharo.org/ Yet I can clearly see it in MetaRepoForPharo50, and the following also works (loaded from MetaRepo) Metacello new configuration: 'IconFactory'; smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo50'; load Did I miss something? Because it used to be there and now its gone. Thanks, Peter

March 1, 2016

Re: [Pharo-users] CMD/CTRL-B for browsing?

by Luc Fabresse

ok. #Luc 2016-03-01 18:10 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 01 Mar 2016, at 18:06, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > > > Hi Guys, > > > > In Pharo 5, it seems that CMD/CTRL-B does not work for browsing in some > places such as in GTDebugger right bottom pane. > > Is this on purpose? > > > > > No, still a bug: in non-code mode Rubric does not add the shortcuts. We > should fix that and allow these everywhere. > > Marcus >

March 1, 2016

Garage and VoyageMongo Pharo5 versions for the MOOC

by Luc Fabresse

Hi Guys, I am trying to prepare a ConfigurationOfPharoWeb for the MOOC on Pharo5. So I would be really greatful to have some help ;-) - Garage does not seem to load properly in Pharo 5. - VoyageMongo does not have a Pharo5 version nor a ConfigOf in the MetaRepoForPharo5 Thanks #Luc

March 1, 2016

Re: [Pharo-users] CMD/CTRL-B for browsing?

by Marcus Denker

> On 01 Mar 2016, at 18:06, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi Guys, > > In Pharo 5, it seems that CMD/CTRL-B does not work for browsing in some places such as in GTDebugger right bottom pane. > Is this on purpose? > > No, still a bug: in non-code mode Rubric does not add the shortcuts. We should fix that and allow these everywhere. Marcus

March 1, 2016

CMD/CTRL-B for browsing?

by Luc Fabresse

Hi Guys, In Pharo 5, it seems that CMD/CTRL-B does not work for browsing in some places such as in GTDebugger right bottom pane. Is this on purpose? #Luc

March 1, 2016

[Issue tracker] Please check old issues to prepare for release!

by Marcus Denker

Hello, As you might now, we are in the process of getting Pharo5 stable for a release. One of the things that is always important is to clean the issue tracker: over the year that the new release in in development, lots of issue accumulate. Please, just for the issue you have either opened yourself or where you have been involved in the discussion: -> Is the issue still relevant? Maybe it has been fixed? -> Is it really important to stay open? Sometimes things are just not worth itâ¦ -> Is this really an issue tracker entry? What I mean here is that an issue tracker is not a wish-list. There are so many things I want, but adding an issue is often not helping. âIt would be nice ifââ¦ -> Bugs: Can it be reproduced? How? -> Features: We are in freeze. Likely it should be moved to the âPharo 6â Milestone. We are at 521 open issue as of now, I am sure we can get that number down till we release. At some point (soon) we will make a real âshow stopperâ list for the issue that we have to fix before we can release. Marcus

March 1, 2016

Pharo Days 2016 Pre-Registration

by Sven Van Caekenberghe

Hi, The Pharo Days 2016 are at the end of this month. We are really looking forward to seeing as many of you as possible. The official registration is not yet online, but we need attendance numbers to plan ahead. We therefor ask you to complete the following Doodle if you plan on coming: http://doodle.com/poll/rsc86cqzxbgwr9tr There are 3 time slots: first day, social diner on the first evening, and second day. The schedule and list of talks is not yet final, but a draft is already available: http://pharodays2016.pharo.org At least one slot is not yet defined, feel free to make a suggestion for a topic you would find interesting. In the afternoon, you have the opportunity to do informal, demo style presentations of your work to small groups. Regards, The Pharo Board

March 1, 2016

Re: [Pharo-users] Fwd: Pharo Consortium GSoC 2016 application status

by stepharo

Thanks Serge, Peter and Yuriy for your actions. It is nice to have a good list of topics. We should encourage students from all over the world to work on such topics. Stef Le 1/3/16 08:43, Serge Stinckwich a Ã©crit : > We have no explanation at the moment ... As Stephan already say, there > are usually more applications that slots available. > The problem is not be rejected, but to be rejected since 3 years (in > 2014 with Squeak and in 2015 only as Pharo). > > Thank you my co-admins Peter et Uko for the wonderful help. > Thank you to all of you for proposing ideas and projects. > > > On Mon, Feb 29, 2016 at 10:59 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: > > And the reason is... ? > > > > 2016-02-29 17:37 GMT-03:00 <serge.stinckwich(a)gmail.com > <mailto:serge.stinckwich@gmail.com>>: > > > > Sent from my iPhone > > Begin forwarded message: > >> *From:* Google Summer of Code >> <summerofcode-noreply(a)google.com >> <mailto:summerofcode-noreply@google.com>> >> *Date:* 29 fÃ©vrier 2016 21:36:26 UTC+1 >> *To:* sergestinckwich(a)gmail.com >> <mailto:sergestinckwich@gmail.com> >> *Subject:* *Pharo Consortium GSoC 2016 application status* >> >> >> >> Google Summer of Code >> >> Thank you for applying to be a Google Summer of Code 2016 >> mentor organization. Sadly, we were unable to accept Pharo >> Consortium this year. We had many more applications than we >> had available slots this year but we do hope you will apply >> again in the future. >> >> >> >> >> >> >> You are receiving this email because of your participation in >> Google Summer of Code 2016. >> https://summerofcode.withgoogle.com >> >> To leave the program and stop receiving all emails, you can >> go to your profile >> <https://summerofcode.withgoogle.com/dashboard/profile/> and >> request deletion of your program profile. >> >> For any questions, please contact gsoc-support(a)google.com >> <mailto:gsoc-support@google.com>. Replies to this message go >> to an unmonitored mailbox. >> >> Â© 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, >> CA 94043, USA >> >> >> > > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/

March 1, 2016