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

Re: [Pharo-dev] ARM Cogit

by stepharo

Hi alex First we are discussing with inria to see if one of their engineer can work a month to check what jb did. Because JB was revisiting the VM from scratch but he did not finish. It will be on the roadmap for the new engineer the consortium will hire. Second you can find information about the way Jannik deployed Phratch on Android http://www.phratch.com/archives/408 Stef > Hi > > Any news on Pharo VM for android? ;) > > Cheers, > Alex > > On Thu, Apr 23, 2015 at 7:54 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > This is really excellent! > Keep pushing this. > I'm eager to play with a raspberry. > We should continue to revisit the UI elements to consume less in > any case. > Because I'm convinced that we are doing too many things at the > wrong place. > > Stef > > Le 22/4/15 21: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 > > > >

Oct. 7, 2015

Re: [Pharo-dev] Issue Tracker Choice

by stepharo

but on the other hand - it is there - it works (even if I do not like the interface) - it is a pro tools (they should not close in the next 3 months). - so the message is also that we use a pro environment Stef Le 7/10/15 05:30, Sean P. DeNigris a Ã©crit : > Damien Cassou-2 wrote >> could you please tell us what you don't like about FogBugz > The main thing is that it's not designed for open source projects. Requiring > account creation before one can even search the open issues is a huge > barrier. I would guess most new people will hit that wall and give up on > sending us valuable bug reports. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Issue-Tracker-Choice-tp4854002p4854106.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Oct. 7, 2015

Re: [Pharo-dev] UserManager removed - alternative?

by stepharo

;) > Ah, but > http://objology.blogspot.fr/2011/09/one-of-best-bits-of-programming-advice.… > You've got a score of two ending -er in a single class, tsss... ;) > > Nicolas

Oct. 7, 2015

Re: [Pharo-dev] Issue Tracker Choice

by Sean P. DeNigris

Damien Cassou-2 wrote > could you please tell us what you don't like about FogBugz The main thing is that it's not designed for open source projects. Requiring account creation before one can even search the open issues is a huge barrier. I would guess most new people will hit that wall and give up on sending us valuable bug reports. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-Tracker-Choice-tp4854002p4854106.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 7, 2015

Re: [Pharo-dev] UserManager removed - alternative?

by Nicolas Cellier

Ah, but http://objology.blogspot.fr/2011/09/one-of-best-bits-of-programming-advice.… You've got a score of two ending -er in a single class, tsss... ;) Nicolas 2015-10-06 21:53 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Hi Stef, > > Thanks for explanation! I agree and looking forward to see a new solution > :) > > Cheers, > Alex > > On Tue, Oct 6, 2015 at 8:26 AM, stepharo <stepharo(a)free.fr> wrote: > >> Hi Aliak >> >> The design of the UserManager was ****plain**** bad. It was reintroducing >> this ugly facade singleton pattern (monolitic and global) >> like the old Preferences class that we fight a lot with alain and >> finally replace by setting. >> It was a mistake that I did not have the time to review the code. (BTW we >> were pushing too much code in the system without >> a good review). Now this period is over. >> >> The solution of the new approach should be the same than settings. >> >> - first any part that should be user managed should do it locally and >> introduce its own hooks to do so >> but be self-contained: exactly like Setting. A class uses class >> variables and check its class variables >> when doing something. >> >> - It means that as a client of the part I can change some accesses. >> >> - then we decorate such user-managed hooks and provide tools. >> >> Stef >> >> >> >> >> >> Bloc is broken because UserManager is no longer in the image. (it was >> removed on 14th of August) >> For some reason there is a check: >> >> UserManager default canDropOSFile >> >> >> this check is used in #dropFiles: >> >> What is alternative or does it make sense to remove the check? >> >> Cheers, >> Alex >> >> >> >

Oct. 6, 2015

Re: [Pharo-dev] ARM Cogit

by Eliot Miranda

Alex, have you tried building a Cog VM from the Cog svn sources? I expect, provided you hack around the NativeBoost uses, that the VM will work. On Tue, Oct 6, 2015 at 12:55 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi > > Any news on Pharo VM for android? ;) > > Cheers, > Alex > > On Thu, Apr 23, 2015 at 7:54 AM, stepharo <stepharo(a)free.fr> wrote: > >> This is really excellent! >> Keep pushing this. >> I'm eager to play with a raspberry. >> We should continue to revisit the UI elements to consume less in any case. >> Because I'm convinced that we are doing too many things at the wrong >> place. >> >> Stef >> >> Le 22/4/15 21: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 >>> >> >> >> > -- _,,,^..^,,,_ best, Eliot

Oct. 6, 2015

Re: [Pharo-dev] FogBugz-Filter

by Peter UhnÃ¡k

https://pharo.fogbugz.com/default.asp?pg=pgManageFilters (button next to cases > manage filters) (or https://pharo.fogbugz.com/default.asp?pg=pgFilter&ixFilter=36 ) Maybe caused by this http://forum.world.st/issue-tracker-6-issue-fixed-in-external-package-needs… ? On Tue, Oct 6, 2015 at 10:15 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Someone changed the fogbugz filter "Fixed To Review" now it shows the same > results like "fixed upstream", how can it be changed it back? >

Oct. 6, 2015

FogBugz-Filter

by Nicolai Hess

Someone changed the fogbugz filter "Fixed To Review" now it shows the same results like "fixed upstream", how can it be changed it back?

Oct. 6, 2015

Re: [Pharo-dev] ARM Cogit

by Aliaksei Syrel

Hi Any news on Pharo VM for android? ;) Cheers, Alex On Thu, Apr 23, 2015 at 7:54 AM, stepharo <stepharo(a)free.fr> wrote: > This is really excellent! > Keep pushing this. > I'm eager to play with a raspberry. > We should continue to revisit the UI elements to consume less in any case. > Because I'm convinced that we are doing too many things at the wrong place. > > Stef > > Le 22/4/15 21: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 >> > > >

Oct. 6, 2015

Re: [Pharo-dev] UserManager removed - alternative?

by Aliaksei Syrel

Hi Stef, Thanks for explanation! I agree and looking forward to see a new solution :) Cheers, Alex On Tue, Oct 6, 2015 at 8:26 AM, stepharo <stepharo(a)free.fr> wrote: > Hi Aliak > > The design of the UserManager was ****plain**** bad. It was reintroducing > this ugly facade singleton pattern (monolitic and global) > like the old Preferences class that we fight a lot with alain and > finally replace by setting. > It was a mistake that I did not have the time to review the code. (BTW we > were pushing too much code in the system without > a good review). Now this period is over. > > The solution of the new approach should be the same than settings. > > - first any part that should be user managed should do it locally and > introduce its own hooks to do so > but be self-contained: exactly like Setting. A class uses class > variables and check its class variables > when doing something. > > - It means that as a client of the part I can change some accesses. > > - then we decorate such user-managed hooks and provide tools. > > Stef > > > > > > Bloc is broken because UserManager is no longer in the image. (it was > removed on 14th of August) > For some reason there is a check: > > UserManager default canDropOSFile > > > this check is used in #dropFiles: > > What is alternative or does it make sense to remove the check? > > Cheers, > Alex > > >

Oct. 6, 2015