- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] QualityImprovements assured by tests

by Stephane Ducasse

I agree with you. This is why I worked on the auto categoriser. then I improve the categorizer inside the image. Now I have a tool to analyse the categories but no time and I did not want to break everything but we could push some rules. if people would have published slices on such issues I'm quite sure that we would have integrated them, now the question is that it takes time and we were focused on other urgent tasks. Stef On Sat, May 20, 2017 at 12:25 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > One year later we are close to a final release for Pharo 6 and either with > Pharo 6 or upcoming Pharo 7 > I would really like to see some checks that ensure a quality image and > tests who keep us all more > disciplined in the future. > > Because: > > 1. We should not have undocumented classes: > > (Object allSubclasses select: [:cls| cls hasComment not ]) > > but we have a lot in Pharo 6 now since we introduced new packages in > this release iteration > > 2. We should not have class instance variables in uppercase but: > > (Object allSubclasses select: [:cls| cls isMeta]) select: [:cls| cls > instVarNames anySatisfy: [:n | n first isUppercase]] > > is not empty - although this was already discussed back in 2008 (!), > see > http://lists.pharo.org/pipermail/pharo-dev_lists. > pharo.org/2008-November/003366.html > > 3. We should not have uncategorized methods but: > > (Object allSubclasses select: [:cls| (cls selectorsInProtocol: > Protocol unclassified) notEmpty ]) > > we still have them. > > 4. I've seen methods with unused temporary variables. Dont know about > unused ivars or other. > > 5. add you own here ... > > I know this is often boring to comment or categorize - but we should do > our homework as we wanted to > better compared to the past. Also if the base image is not following rules > how should we expect others > to provide quality packages on top of it? > > IMHO we should raise the bar. Either in Pharo 6 or in early Pharo 7. We > can fix these once and for > all AND assure with unit tests that we keep the standard image on this > quality level. > > Thx > T. > > > > >

May 20, 2017

[ bloc]'Pulse loop must be running in order to request a pulse'

by Stephane Ducasse

I wanted to work on the bloc booklet and when I reopen my image I get 'Pulse loop must be running in order to request a pulse'

May 20, 2017

Re: [Pharo-dev] Calypso technology preview.

by Norbert Hartl

> Am 20.05.2017 um 09:54 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi ben > > It is better to load it because for example I could not load a new version the last time I tried to update. > We should lower the stress of the releasers. Yes, and release twice as often ð Norbert > > Stef > > >> On Sat, May 20, 2017 at 4:47 AM, Ben Coman <btc(a)openinworld.com> wrote: >> It is probably much too late to suggest this, but if Calypso is a candidate for our next browser, perhaps it could be included in Pharo 6 as a technology preview? >> Or maybe in a half-year point release Pharo 6.x ? >> >> cheers -ben >

May 20, 2017

Re: [Pharo-dev] Calypso technology preview.

by Stephane Ducasse

Hi ben It is better to load it because for example I could not load a new version the last time I tried to update. We should lower the stress of the releasers. Stef On Sat, May 20, 2017 at 4:47 AM, Ben Coman <btc(a)openinworld.com> wrote: > It is probably much too late to suggest this, but if Calypso is a > candidate for our next browser, perhaps it could be included in Pharo 6 as > a technology preview? > Or maybe in a half-year point release Pharo 6.x ? > > cheers -ben >

May 20, 2017

Re: [Pharo-dev] Embeddable/scalable Smalltalk VM needs funding for release (repost/update from squeak-dev)

by S Krish

Great Work..!! On Mon, May 15, 2017 at 1:01 PM, Zak Fenton <zak.fenton(a)outlook.com> wrote: > Hi folks. I posted earlier in squeak-dev about a Smalltalk implementation > I've been working on. The first post was a bit unwieldy, but there was at > least some interest so I'm posting an update to vm-dev and pharo-dev. > > > Main strong points are that it's embeddable (like Lua or SQLite) and > scalable (like Erlang). There are weak points too, of course (e.g. hot loop > performance will be much worse than Squeak/Pharo at this point). > > > The VM itself is pure C and has no dependencies apart from libc and libm. > It doesn't require a filesystem (you can pipe VM images through custom > stream implementations or arrays) and it should run well in tight (~1MB) > memory situations. > > > The extension system is similar to the Unix system call and virtual > filesystem APIs, so it's kind-of object oriented but in a very "C" way. All > extension resources are managed properly (so the system can clean up safely > and/or warn you if you allocate memory and don't deallocate it, for > example). > > > Extensions are available for cells (threads/individual VMs), shared memory > (so different cells can communicate efficiently - but also with memory > protection and calling features for implementing domain-specific JIT > compilers), windowing and event handling (based on SDL2) and 2D graphics > rendering (based on Cairo). There are some higher-level libraries (stylable > GUI system, tight OS integration, 3D modelling, etc.). > > > It's polished in some ways (there's a test suite, an integrated help > system, colour shell, etc.), but it needs a lot more refinement in others > (the current GUI style is terrible, it needs more documentation, there's > only minimal support for keyboard entry, no networking library, etc.). > > > I'd like to release it (ideally as 100% public domain/CC0), but I don't > want to do so without some way of funding development. The project promises > a lot and I want to actually deliver with some ongoing updates and support > (and being able to pay rent next week would also be a plus), so I'm not > interested in just dumping it on GitHub and calling it a day. > > > So I'm open to any suggestions as to how to fund this project at least in > the short term and how it might fit into the wider Squeak/Pharo/Smalltalk > ecosystems, as well as any technical criticism relating to the > implementation itself. > > > I've put together a basic website describing the implementation in a bit > more detail (sorry, no downloads yet): http://a4vm.info/ > > > -Zak. >

May 20, 2017

Calypso technology preview.

by Ben Coman

It is probably much too late to suggest this, but if Calypso is a candidate for our next browser, perhaps it could be included in Pharo 6 as a technology preview? Or maybe in a half-year point release Pharo 6.x ? cheers -ben

May 20, 2017

Re: [Pharo-dev] Launcher and Pharo 6 Errors on Mac

by Ben Coman

On Sat, May 20, 2017 at 2:02 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Ben Coman wrote > > What do you get installing from the Catalogue into a fresh Image and > > manually updating? > > When you say "fresh image", what do you have in mind because I got the same > error with a Pharo 6 from the CI, so it doesn't seem to be a launcher > issue. > Just that. Isolating the problem between Launcher or Pharo > Sorry if I was not clear... > > cool. cheers -ben

May 20, 2017

ReÂ : [Pharo-dev] QualityImprovements assured by tests

by Benoit St-Jean

How about a sprint? I surely am not the most qualified person to comment a class I did not create but we can all remove crap !Â EnvoyÃ© Ã partir de YahooÂ Courriel sur Android Le ven., mai 19 2017 Ã 18:26, Torsten Bergmann<astares(a)gmx.de> a Ã©critÂ : Hi, One year later we are close to a final release for Pharo 6 and either with Pharo 6 or upcoming Pharo 7 I would really like to see some checks that ensure a quality image and tests who keep us all more disciplined in the future. Because: Â 1. We should not have undocumented classes: Â Â Â Â (Object allSubclasses select: [:cls| cls hasComment not ]) Â Â but we have a lot in Pharo 6 now since we introduced new packages in this release iteration Â 2. We should not have class instance variables in uppercase but: Â Â (Object allSubclasses select: [:cls| cls isMeta]) select: [:cls| clsÂ Â Â Â instVarNames anySatisfy: [:n | n first isUppercase]] Â Â is not empty - although this was already discussed back in 2008 (!), see Â Â http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2008-November/00… Â 3. We should not have uncategorized methods but: Â Â (Object allSubclasses select: [:cls| (cls selectorsInProtocol: Protocol unclassified) notEmpty ]) Â Â we still have them. Â 4. I've seen methods with unused temporary variables. Dont know about unused ivars or other. Â 5. add you own here ... I know this is often boring to comment or categorize - but we should do our homework as we wanted to better compared to the past. Also if the base image is not following rules how should we expect others to provide quality packages on top of it? IMHO we should raise the bar. Either in Pharo 6 or in early Pharo 7. We can fix these once and for all AND assure with unit tests that we keep the standard image on this quality level. Thx T.

May 20, 2017

QualityImprovements assured by tests

by Torsten Bergmann

Hi, One year later we are close to a final release for Pharo 6 and either with Pharo 6 or upcoming Pharo 7 I would really like to see some checks that ensure a quality image and tests who keep us all more disciplined in the future. Because: 1. We should not have undocumented classes: (Object allSubclasses select: [:cls| cls hasComment not ]) but we have a lot in Pharo 6 now since we introduced new packages in this release iteration 2. We should not have class instance variables in uppercase but: (Object allSubclasses select: [:cls| cls isMeta]) select: [:cls| cls instVarNames anySatisfy: [:n | n first isUppercase]] is not empty - although this was already discussed back in 2008 (!), see http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2008-November/00… 3. We should not have uncategorized methods but: (Object allSubclasses select: [:cls| (cls selectorsInProtocol: Protocol unclassified) notEmpty ]) we still have them. 4. I've seen methods with unused temporary variables. Dont know about unused ivars or other. 5. add you own here ... I know this is often boring to comment or categorize - but we should do our homework as we wanted to better compared to the past. Also if the base image is not following rules how should we expect others to provide quality packages on top of it? IMHO we should raise the bar. Either in Pharo 6 or in early Pharo 7. We can fix these once and for all AND assure with unit tests that we keep the standard image on this quality level. Thx T.

May 19, 2017

Re: [Pharo-dev] Chrome DevTools Protocol and Pharo

by Alistair Grant

Hi Torsten, On Fri, May 19, 2017 at 10:50:41PM +0200, Torsten Bergmann wrote: > Hi Alistair, > > cant look right now but two things: > > - there are also events in the protocol - if we could hook Pharo into them > this would solve the problem without abusing delay (because then you will > get informed when the page loading is finished) That would be great. It will be a while before I get a chance to look at this (I want to finish some proposed changes to the FileSystem packages first), but I'll try and include it then. > - you can write "5 seconds wait" in Pharo Thanks for the tip (I'm still transitioning from VW 2.5 :-)). > > Bye > T. > > > > Gesendet: Freitag, 19. Mai 2017 um 17:51 Uhr > > Von: "Alistair Grant" <akgrant0710(a)gmail.com> > > An: pharo-dev(a)lists.pharo.org > > Betreff: Re: [Pharo-dev] Chrome DevTools Protocol and Pharo > > > > On Fri, May 19, 2017 at 01:50:28PM +0200, Torsten Bergmann wrote: > > > Alistair Grant wrote > > > > > > > This looks really interesting, thanks for making it available. I'm on > > > > linux, so I guess it will need some porting. > > > > > > I added support for Linux and tried on Ubuntu with Chromium. Works - see screenshot > > > > Fantastic, thanks! > > > > I did have to change your script for it to work on my laptop: > > > > 1. isInDebugMode is false by default, which meant that chrome wasn't > > launched with remote debugging enabled. > > > > 2. Retrieving the remotes in GoogleChrome class>>tabPages failed because > > the browser hadn't had time to start up. I'll submit a pull request > > which adds a retry with delay. I've submitted the PR to ping the browser while it starts up, and add /opt/google/chrome/chrome as a known location. Thanks again, Alistair > > 3. I initially got a white image. This appears to be because the script > > doesn't wait for the navigation to complete before taking the > > screenshot. I just added an ugly delay, but I'm not yet sure what the best > > solution here is. > > > > > > | chrome page | > > > > chrome := GoogleChrome new > > debugOn; > > open; > > yourself. > > page := chrome tabPages first. > > page navigateTo: 'http://www.pharo.org'. > > (Delay forSeconds: 5) wait. > > page captureScreenshot scaledToSize: 200@300. > > > > > > > You need to load my OSLinux package (instead of OSOSX) from catalog. Or start > > > Chrom manually in debug mode. > > > > > > In the Pharo settings browser you can set the path to the chrome executable > > > and the debug port to use. > > > > I doubt that the chrome executable is in that many different places. > > Would you be open accepting a pull request which adds (what I assume is) > > the Ubuntu 16.04 default location? > > > > > > > Will add Windows support as well (using my OSWindows package) > > > > > > > Do you know how the DevTools protocol relates to headless chome, which > > > > will be available in Chrome 59? > > > > See https://developers.google.com/web/updates/2017/04/headless-chrome > > > > > > Dont know - just try it. > > > > > > > In particular, is it possible to dump the DOM with your package? > > > > > > I've seen that Brackets editor as well as Netbeans open Chrome to > > > display webpages when editing and refresh when typing. Wanted > > > to find out how it was done. > > > > > > I have not implemented the full protocol. Only what was needed to show > > > that it is possible and to do things like grabbing screenshots from websites > > > using Pharo. > > > > I've found a page that describes accessing the DOM, so it looks like it > > should be possible. I'll see what I can do... > > > > > There is a DOM domain that one could wrap - basically it is just > > > sending JSON around, see > > > https://chromedevtools.github.io/devtools-protocol > > > > > > With > > > > > > chrome := GoogleChrome open. > > > chrome jsProtocolJSON. > > > chrome browseProtocolJSON > > > > > > you can now even retrieve the Protocol as JSON for the specific browser. > > > With a little bit more work it should be possible to even generate > > > the wrapper classes/methods from such a protocol spec.

May 19, 2017