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

Re: [Pharo-dev] Transcript needs your love

by phil＠highoctane.be

Guess we need a World doOneCycle somewhere. That's how I get my things to the Transcript in long loops. Or use VTermOutputDriver which logs to the console. Phil On Fri, May 8, 2015 at 11:34 AM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > the Transcript in Pharo is that it's not asynchronous so I can't use it in > VM development to show the current progress of the simulation. For example: > 1 to: 100 do: [ :i | > 0.1 seconds asDelay wait. > Transcript show: 'x'. ] > => on Squeak, this shows a x every 0.1 second in the Transcript > => on Pharo, nothing happens during 10 seconds then all the x are shown. > > https://pharo.fogbugz.com/default.asp?15515 > >

May 8, 2015

Re: [Pharo-dev] Transcript needs your love

by Sven Van Caekenberghe

But [ 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x' ] ] fork works as expected ... IOW, the Doit blocks the UI thread, I guess. > On 08 May 2015, at 11:34, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: > 1 to: 100 do: [ :i | > 0.1 seconds asDelay wait. > Transcript show: 'x'. ] > => on Squeak, this shows a x every 0.1 second in the Transcript > => on Pharo, nothing happens during 10 seconds then all the x are shown. > > https://pharo.fogbugz.com/default.asp?15515 >

May 8, 2015

Transcript needs your love

by stepharo

Hi guys the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x'. ] => on Squeak, this shows a x every 0.1 second in the Transcript => on Pharo, nothing happens during 10 seconds then all the x are shown. https://pharo.fogbugz.com/default.asp?15515

May 8, 2015

Re: [Pharo-dev] Testers needed! Re: Athens BitBlt bug?

by Nicolai Hess

2015-05-08 10:05 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi > > 2015-05-08 1:43 GMT+03:00 Nicolai Hess <nicolaihess(a)web.de>: > >> load bleeding edge from Bloc > > > Code for loading it can be very helpfull > :) Gofer new smalltalkhubUser: 'Pharo' project: 'Bloc'; load; configurationOf: 'Bloc'; loadBleedingEdge

May 8, 2015

Re: [Pharo-dev] Testers needed! Re: Athens BitBlt bug?

by Denis Kudriashov

Hi 2015-05-08 1:43 GMT+03:00 Nicolai Hess <nicolaihess(a)web.de>: > load bleeding edge from Bloc Code for loading it can be very helpfull

May 8, 2015

Re: [Pharo-dev] Selected context specific debugger action

by Tudor Girba

Of course, it can be loaded into Pharo :) (Moose is anyway just some packages loaded into Pharo). You get it if you load the full GToolkit. Right now, in Pharo you have only GToolkitCore. We load it like this in a Pharo 4 (for now): Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTSpotter'; package: 'ConfigurationOfGTPlayground'; package: 'ConfigurationOfGTInspector'; package: 'ConfigurationOfGTInspectorCore'; package: 'ConfigurationOfGTPlaygroundCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'Pharo' project: 'Rubric'; package: 'ConfigurationOfRubric'; load. Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; configuration; loadDevelopment Cheers, Doru On Fri, May 8, 2015 at 12:08 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Uko2 wrote > > where should I start to look in GTDebugger > > Can this be loaded into Pharo, or is is just for Moose? > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Selected-context-specific-debugger-action-tp4825049p4… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

May 8, 2015

Re: [Pharo-dev] [Vm-dev] Pending OS-X Cocoa Squeak VM build

by David T. Lewis

On Thu, May 07, 2015 at 11:42:41AM -0700, John McIntosh wrote: > > Morning. > > I've taken some time to integrate various Pharo and Pyonkee changes into > the Squeak OS-X and iOS cocoa source tree, along with converting the code > base to ARC and modern Obj-C. > > Earlier today I ran a Squeak4.5-13680 32bit image on a 64bit client > 3488 run, 3421 passes, 23 expected failures, 43 failures, 0 errors, 1 > unexpected passes > > However I need some folks to step forward and validate the results, > document what might be broken, look for behaviour anomalies, and refine > exactly what plugins are needed in the base system. > > I also need someone to try this on a 32bit host with 32bit image, and with > a current 64bit image (which I don't have) on a 64bit host. Hi John, You can download a current 64-bit image from http://build.squeak.org/job/Squeak%2064-bit%20image/ This is an updated trunk image traced freshly on a daily basis. It is a traditional 68002 64-bit image (not the Spur 68019 64-bit image format). Dave > > Drop me a note and I"ll forward a link to a binary for testing. > > Shortly I will be integrating these changes into the Cog branch and create > an XCode project for building a 64/64 Cog/etc VM. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > https://www.linkedin.com/in/smalltalk > ===========================================================================

May 8, 2015

Re: [Pharo-dev] Penelope Doesn't Skip "Wrong" Lint Rules

by Sean P. DeNigris

Ben Coman wrote > How about we open an issue for this, and temporarily introduce a new > package CaseNNNN for > testing this, where Sean could reproduce his case. I have also experienced what you're talking about - that Lint rules were failing that were not introduced with my fix; but I also was unable to properly document them. Just to be clear, this is a different problem - namely, that manifests declarations of wrong rules are not honored i.e. they are still reported as errors/warnings. As Nicolai pointed out in a comment in issue 15507, maybe this is a good thing because human reviewers may want to check that they were properly marked "wrong". But ideally, they would be reported as two separate categories - 1. new failures not marked "wrong" and 2. new failures so marked ----- Cheers, Sean -- View this message in context: http://forum.world.st/Penelope-Doesn-t-Skip-Wrong-Lint-Rules-tp4825134p4825… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 8, 2015

Re: [Pharo-dev] Penelope Doesn't Skip "Wrong" Lint Rules

by Ben Coman

----- Sean P. DeNigris <sean(a)clipperadams.com> a Ã©crit : > I marked them wrong in the Critic Browser, which now skips them, but the > validation report still shows them as Warnings. Anyone know why? I see the > versions in the inbox references by the slice have their manifest classes... On Fri, May 8, 2015 at 4:00 AM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > The monkey does a first run of tests/critics with the current pharo image > ans store failed tests/rules. Then, it loads the slice and does a second > run. At the end, issues reported are only the new failed tests/ rules. > That is how I understand it should work, but I've found that it doesn't always work in practice. Though at the time I thought it might just be me and I didn't stop to extract a reproducible case. And then once an issue is integrated, its not there for troubleshooting. How about we open an issue for this, and temporarily introduce a new package CaseNNNN for testing this, where Sean could reproduce his case. cheers -ben

May 8, 2015

Re: [Pharo-dev] Testers needed! Re: Athens BitBlt bug?

by Nicolai Hess

the code (reverting igors change for the 1 pixel extra height) 2015-05-08 0:43 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > Some testers needed! > > I can not reproduce the BitBlt bug and I would like to get this right, so > that surface pattern > paints use the correct form dimension. > > Prefered test setup: > a (fresh) pharo image > load bleeding edge from Bloc (because with bloc the whole (morphic) world > is drawn with athens). > change to watery theme ( because it makes some heavy use of form fills) > verify that vertical scrollbars have this artifact (blank lines). > load the attached code (this code reverts igors change for the 1 pixel > extra height. > > please report back > what platform windows/linux/mac 32/64 bit > what pharo vm and image version. > > For me > Windows 7 32 bit > Win32 built on Apr 9 2015 21:05:04 Compiler: 4.6.2 > Latest update: #50039 > > -> no segfault > > thanks in advance > > > 2015-03-13 21:22 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> I do not know. May be igor is reading this mailing-list but I doubt. >> >> >> 2015-01-27 21:46 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> >> Anyone knows what this BitBlt bug is or was? >>> 12818 <https://pharo.fogbugz.com/default.asp?12818> Last row missing >>> 13236 <https://pharo.fogbugz.com/default.asp?13236> Fix 1 extra height >>> for Cairo surface >>> >>> Because with the fix in 13236, it is not (easily) possible to make >>> a repeating (vertical) pattern paint with 1 pixel height: >>> 14813 <https://pharo.fogbugz.com/default.asp?14813> Wrong size for >>> Athens surface pattern paint from a Form >>> >>> >>> nicolai >>> >>> >>> >> BUMP >> >> >> >> >> >> >

May 7, 2015