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

Re: [Pharo-dev] [Vm-dev] ARM Cogit

by Eliot Miranda

Hi Holger, On Wed, Apr 22, 2015 at 11:52 AM, Holger Freyther <holger(a)freyther.de> wrote: > > > > On 22 Apr 2015, at 14:42, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi, > > > thanks to hard work by Tim Rowledge and Lars Wasserman we now have a > functional JIT for the ARM in the simulator. We're still probably some > weeks away from a functional ARM JIT VM; issues like instruction cache > flushing on real hardware can be tricky to solve. But we're at least ready > to start trying to compile the JIT VM for ARM. Doug, see that I added a > build directory for build.linux32ARM/squeak.cog.spur. Hopefully a fast VM > for Raspberry Pi and Android is only a few weeks away. > > tricky in which sense? The Linux kernel offers a syscall (cacheflush) > where one > provides the start page and end page and GCC provides a builtin function > for this > as well (__clear_cache). > that's good news. It wasn't always that easy. When we got the ARM JIT working for VisualWorks we had to use hand-rolled code to flush the cache as linux didn't provide a reliable function at that time. So perhaps we're closer than we think. But it's always wise to lengthen time estimates, not shorten them :-) holger > > > cache flush: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/a… -- best, Eliot

April 22, 2015

Re: [Pharo-dev] ARM Cogit

by Douglas McPherson

> On Apr 22, 2015, at 11:42, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi All, > > thanks to hard work by Tim Rowledge and Lars Wasserman we now have a functional JIT for the ARM in the simulator. We're still probably some weeks away from a functional ARM JIT VM; issues like instruction cache flushing on real hardware can be tricky to solve. But we're at least ready to start trying to compile the JIT VM for ARM. Doug, see that I added a build directory for build.linux32ARM/squeak.cog.spur. Hopefully a fast VM for Raspberry Pi and Android is only a few weeks away. > -- > best, > Eliot +1000 This is terrific news! Thanks to you, Tim, and Lars! Doug

April 22, 2015

Pb when exporting setting?

by Alexandre Bergel

Hi! I have an error: KeyNotFound: key #âWeight Below Thresholdâ not found in SystemDictionary Any idea whatâs going on? How can I reset the export? Where is this file by the way? I could not find it. cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 22, 2015

Re: [Pharo-dev] [Vm-dev] ARM Cogit

by Holger Freyther

> On 22 Apr 2015, at 14:42, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: Hi, > thanks to hard work by Tim Rowledge and Lars Wasserman we now have a functional JIT for the ARM in the simulator. We're still probably some weeks away from a functional ARM JIT VM; issues like instruction cache flushing on real hardware can be tricky to solve. But we're at least ready to start trying to compile the JIT VM for ARM. Doug, see that I added a build directory for build.linux32ARM/squeak.cog.spur. Hopefully a fast VM for Raspberry Pi and Android is only a few weeks away. tricky in which sense? The Linux kernel offers a syscall (cacheflush) where one provides the start page and end page and GCC provides a builtin function for this as well (__clear_cache). holger cache flush: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/a…

April 22, 2015

Re: [Pharo-dev] ARM Cogit

by Thierry Goubier

Yes! Thanks to all for that effort. Thierry Le 22/04/2015 20:42, Eliot Miranda a Ã©crit : > Hi All, > > thanks to hard work by Tim Rowledge and Lars Wasserman we now have > a functional JIT for the ARM in the simulator. We're still probably > some weeks away from a functional ARM JIT VM; issues like instruction > cache flushing on real hardware can be tricky to solve. But we're at > least ready to start trying to compile the JIT VM for ARM. Doug, see > that I added a build directory for build.linux32ARM/squeak.cog.spur. > Hopefully a fast VM for Raspberry Pi and Android is only a few weeks away. > -- > best, > Eliot

April 22, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by Thierry Goubier

Le 22/04/2015 20:05, stepharo a Ã©crit : > >> The thing is, if you are not doing it, you're asking someone else to >> do it for you. >> >> So, some of the possibilities are: >> >> - Decouple a bit upstream from Pharo/main, not merging everything from >> there immediately. Wait to see the fixes and changes to stabilize, >> then extract and merge. >> >> - Wait for Pharo/main to pushes fixes to you upstream. So that >> Pharo/main has a duty of collecting the changes, making them all in a >> nice pack, and send them your way. >> >> A good thing is to adjust the process so that pushing things back and >> forth is easing the task of everybody involved (motivation!). >> >> For example, if an hypothetical Stef (not the true one :)) is changing >> and fixing things in Rubric inside Pharo/main, it will make merging >> Rubric newest version harder. > Why? > As a maintainer of Rubric, you know the system, its current development > status. > So you can decide when you reconcile with the Pharo version. > I would say that Pharo core hackers should not integrate changes in > external packages (only in urgence) I agree. What I said is that if Pharo core hackers do not take a bit of time to package and push upstream (i.e. to the external project) their fixes, then it will be hard for the external project maintainer to reconcile Pharo and his stream. Note that as the Rubric maintainer, if I go on holiday for three weeks, I may have to cope with a jump of around 30 to 50 versions of Pharo main to adjust too... If this happens to be the period you go on a fixing bug chase over Rubric, then the merge may be a tad challenging ;) >> So, a good thing would be to make that hypothetical Stef in charge of >> merging the new Rubric version as well. If he finds it a pain, then he >> will ease his tasks by sending his fixes nicely packaged to the Rubric >> maintainer, so that the Rubric manager can merge that with the newest >> version and send it back to Pharo/main for integration by our >> hypothetical Stef :) >> >> However, it would be allways possible for an external project to make >> it easier to fix in their project directly than in Pharo/main, but for >> that they need to be very reactive (make sure that fixes are >> propagated back very fast in Pharo/main) and make the process as easy >> as possible for an external contributor... > I do not think that putting the stress on external projects to merge > fast is good. I consider that some external projects sufficiently staffed may want to react this way. Up to them... > Because you can be in the middle of something. > Of course with a correct branch it can be simpler but we do not have > such tool right now. In fact, we do. Apart of the github/bitbucket kind of stuff, it is also possible to use smalltalkhub in that way. It's just a matter of organizing your projects and branches (with one smalltalkhub repository per branch). If you organize yourself that way, you'll end up being very close to a git / branch type of approach. Thierry

April 22, 2015

ARM Cogit

by Eliot Miranda

Hi All, thanks to hard work by Tim Rowledge and Lars Wasserman we now have a functional JIT for the ARM in the simulator. We're still probably some weeks away from a functional ARM JIT VM; issues like instruction cache flushing on real hardware can be tricky to solve. But we're at least ready to start trying to compile the JIT VM for ARM. Doug, see that I added a build directory for build.linux32ARM/squeak.cog.spur. Hopefully a fast VM for Raspberry Pi and Android is only a few weeks away. -- best, Eliot

April 22, 2015

Re: [Pharo-dev] QualityAssistant v0.4

by Marcus Denker

> On 22 Apr 2015, at 20:08, stepharo <stepharo(a)free.fr> wrote: > > NO NO NO integration in the image. > NO external tools to talk to. NO NO NO Change your mindset. But that will get quite hard: If we improve and people create more tools, then the âPharo that could beâ (with the tools loaded) will be very different from the âPharo that isâ. And nobody who downloads pharo will load additional tools. Nobody. Our goal of a modular and minimal image should not mean that Pharo itself does not come with those tools that we want people to use by default. Marcus

April 22, 2015

Re: [Pharo-dev] TDD and BDD

by stepharo

Christophe I do not have the answer just the constraints. This is hyper important that the solution does not change much SUnit. This way we do not end up with a mess with Sunit version. It is better to have a separate package. Stef Le 20/4/15 13:02, Christophe Demarey a Ã©crit : > Hi, > > With BDD a current test practice is to start method names with 'should'. > It is not yet possible in Pharo but easily do-able (update of TestCase and some Nautilus methods). > I would like that Pharo detects tes methods all methods of a class subclassing (directly or not) TestCase AND starting with either 'test' or 'should'. > I also would like to add 'deny' to not use 'shouldNot' but here I'm not sure. > > WDYT? > > Christophe. >

April 22, 2015

Re: [Pharo-dev] WhatsUp from: 2015-04-20 until: 2015-04-30

by stepharo

From what I know: the configruation of OSWindow in the repo is not loaded when there is a configuration in the image. Kind of Le 22/4/15 08:31, Tudor Girba a Ã©crit : > Could JB describe the problem with Metacello? Perhaps there is a > workaround. > > Doru > > On Tue, Apr 21, 2015 at 3:27 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > Hi phil > > just that you know what we are doing > > - Mathieu Lacatou an intern from Thales should be > visiting the team for > 10 days to pair program with esteban > about the OSWindow multi-windowing support > > - JB and Merwan are extending the OSWindow touch > support, like > generating scroll events > > - JB is working on Woden and adding some shadders for > 3D demoes. > > I will have a new guy from Senegal starting to work tomorrow > in my lab > on using GPU and Wooden for doing SPH&epidemiological modeling. > How to coordinate all these activities ? > > > Cool :) > I do not know > For now he should have a look at Woden, JB planned to make a CI. > But he was blocked because of a bug in the old version of > Metacello that we use. > So as soon as Metacello is updated, JB can continue his build. > > Stef > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

April 22, 2015