December 2017 - Pharo-users

Re: [Pharo-users] PharoThings - Metacello installation broken

by Denis Kudriashov

Thank's for report. I fixed it. Try again. I will set up travis to cover such problems. I never tested it on fresh computer 2017-12-03 16:48 GMT+01:00 bachitoph <cj-bachinger(a)gmx.de>: > Hi, > I'm just trying https://github.com/pharo-iot/PharoThings. But if > installing > the client side as suggested below. > > Install the client part of PharoThings in the development (client) Pharo > image: > > Metacello new > baseline: 'PharoThings'; > repository: 'github://pharo-iot/PharoThings/src'; > load: 'RemoteDev' > > After some loading I get the Metacello message > > github--pharoiotFirmatav01x157812618139788200831786773995104653406.zip > does > not exist. > > I tried this under Windows10 with fresh loaded Pharo 6.1 from > www.pharo.org. > > any hints? > > thanks > cjb > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Dec. 3, 2017

Re: [Pharo-users] Glorp v130 call for testing

by Alistair Grant

On 1 December 2017 at 13:46, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Everyone, > > There haven't been any complaints about the merged version, and Glorp > fails to load #development on Pharo 7, so I'm planning to update > ConfigurationOfGlorp to: > > - Work on Pharo7 when given the #development symbolic version > - Make Glorp-AlistairGrant.130 the stable version - up from > Glorp-HerbyVojcik.127. > > If I don't hear any objections in the next couple of days I'll make the change. I haven't heard any objections, so... ConfigurationOfGlorp-AlistairGrant.63: - Promote Glorp-AlistairGrant.130 to stable - Add Pharo 7 support to #development symbolic version Cheers, Alistair

Dec. 3, 2017

PharoThings - Metacello installation broken

by bachitoph

Hi, I'm just trying https://github.com/pharo-iot/PharoThings. But if installing the client side as suggested below. Install the client part of PharoThings in the development (client) Pharo image: Metacello new baseline: 'PharoThings'; repository: 'github://pharo-iot/PharoThings/src'; load: 'RemoteDev' After some loading I get the Metacello message github--pharoiotFirmatav01x157812618139788200831786773995104653406.zip does not exist. I tried this under Windows10 with fresh loaded Pharo 6.1 from www.pharo.org. any hints? thanks cjb -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 3, 2017

Re: [Pharo-users] valueUnpreemptively breaks coverage with ZnClient

by Richard Sargent

Necessary? I can't see that. It seems patently wrong once you consider the cases that cannot be supported. On Dec 2, 2017 12:02, "Sven Van Caekenberghe" <sven(a)stfx.eu> wrote: > > > > On 2 Dec 2017, at 17:21, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > After much digging as to why my tests are timing out even though running > directly was always fine... I found out that TestRunner's coverageRun is > using #valueUnpreemptively to run all tests. > > > > The problem is that one of the tests is retrieving something over > network, and that apparently doesn't go well together. > > > > This works > > > > [ (ZnEasy get: 'http://example.com') entity contents ] value > > > > This freezes the image forever and runs a CPU core at 100% > > > > [ (ZnEasy get: 'http://example.com') entity contents ] > valueUnpreemptively > > > > Is there some resolution to this? > > > > Thanks, > > Peter > > Yes that is weird. > > Just to be 100% clear, it fails with existing websites too. > > [ ZnEasy get: 'http://pharo.org' ] valueUnpreemptively. > > The reason this does not work probably has to do with scheduling. > Socket(Stream)s are non-blocking, they use semaphores internally (in > cooperation with the VM who is probably using something like the select > system call) so that control returns to the image when waiting for IO. > > Note also the comment ! > > BlockClosure>>valueUnpreemptively > "Evaluate the receiver (block), without the possibility of > preemption by higher priority processes. Use this facility VERY sparingly!" > "Think about using Block>>valueUninterruptably first, and think > about using Semaphore>>critical: before that, and think about redesigning > your application even before that! > After you've done all that thinking, go right ahead and use it..." > > The question is, is its use in the coverage tool necessary ? > > Sven > > > > >

Dec. 3, 2017

Re: [Pharo-users] tonel how to

by Esteban Lorenzano

> On 2 Dec 2017, at 20:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Peter UhnÃ¡k wrote >> or you can use monticello with >> "tonel://" scheme (in P61 you will need newest iirc metacello). > > Hmm. IMHO these implementation-revealing url schemes stink. IIRC there is a > gitlocal:// in some contexts. This seems a little better. Can't we > autodetect the format instead of having to change every URL each time the > format changes? iceberg autodetect formats (hence the gitlocal stuff). but others canât, so there is the reason why along with âgitlocalâ there is a âformat-revealingâ url. (btw, http and others are also ârevealingâ) :) Esteban > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Dec. 2, 2017

Re: [Pharo-users] valueUnpreemptively breaks coverage with ZnClient

by Sven Van Caekenberghe

> On 2 Dec 2017, at 17:21, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > After much digging as to why my tests are timing out even though running directly was always fine... I found out that TestRunner's coverageRun is using #valueUnpreemptively to run all tests. > > The problem is that one of the tests is retrieving something over network, and that apparently doesn't go well together. > > This works > > [ (ZnEasy get: 'http://example.com') entity contents ] value > > This freezes the image forever and runs a CPU core at 100% > > [ (ZnEasy get: 'http://example.com') entity contents ] valueUnpreemptively > > Is there some resolution to this? > > Thanks, > Peter Yes that is weird. Just to be 100% clear, it fails with existing websites too. [ ZnEasy get: 'http://pharo.org' ] valueUnpreemptively. The reason this does not work probably has to do with scheduling. Socket(Stream)s are non-blocking, they use semaphores internally (in cooperation with the VM who is probably using something like the select system call) so that control returns to the image when waiting for IO. Note also the comment ! BlockClosure>>valueUnpreemptively "Evaluate the receiver (block), without the possibility of preemption by higher priority processes. Use this facility VERY sparingly!" "Think about using Block>>valueUninterruptably first, and think about using Semaphore>>critical: before that, and think about redesigning your application even before that! After you've done all that thinking, go right ahead and use it..." The question is, is its use in the coverage tool necessary ? Sven

Dec. 2, 2017

Re: [Pharo-users] tonel how to

by Sean P. DeNigris

Peter UhnÃ¡k wrote > or you can use monticello with > "tonel://" scheme (in P61 you will need newest iirc metacello). Hmm. IMHO these implementation-revealing url schemes stink. IIRC there is a gitlocal:// in some contexts. This seems a little better. Can't we autodetect the format instead of having to change every URL each time the format changes? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Dec. 2, 2017

Re: [Pharo-users] tonel how to

by Hilaire

ok, I got it to work with gofer: Gofer new Â Â Â url: 'tonel:///home/hilaire/Travaux/Developpement/DrGeoII/trunk/src'; Â Â Â package: 'ConfigurationOfDrGeo'; Â Â Â load. Le 01/12/2017 Ã 18:07, Hilaire a Ã©critÂ : > I am using P7. > > I already have a tonel export done[1], I need to find what is the > magic to use with monticello or metacello to load the code from a > local repo in tonel format > > Hilaire -- Dr. Geo http://drgeo.eu

Dec. 2, 2017

valueUnpreemptively breaks coverage with ZnClient

by Peter UhnÃ¡k

After much digging as to why my tests are timing out even though running directly was always fine... I found out that TestRunner's coverageRun is using #valueUnpreemptively to run all tests. The problem is that one of the tests is retrieving something over network, and that apparently doesn't go well together. This works [ (ZnEasy get: 'http://example.com') entity contents ] value This freezes the image forever and runs a CPU core at 100% [ (ZnEasy get: 'http://example.com') entity contents ] valueUnpreemptively Is there some resolution to this? Thanks, Peter

Dec. 2, 2017

Re: [Pharo-users] How do you store and manage small programs?

by Bernhard Pieber

That was the problem. Thanks, Norbert! Bernhard > Am 02.12.2017 um 17:01 schrieb Norbert Hartl <norbert(a)hartl.name>: > > That most probably means there are no files in the directory. If you create one then you will see. > > Norbert > >> Am 02.12.2017 um 15:02 schrieb Bernhard Pieber <bernhard(a)pieber.com>: >> >> Hi Norbert, >> >> I tried this in a 6.1 image but I only get a normal inspector. What do I miss? >> >> Bernhard >> >>> Am 26.11.2017 um 13:36 schrieb Norbert Hartl <norbert(a)hartl.name>: >>> >>> Andy, >>> >>> I use the filesystem for it. Letâs say you have a directory called âscriptsâ. If you inspect >>> >>> âscriptsâ asFileReference >>> >>> you get kind of a browser of the files in there. If the have the file extension .st syntax highlighting is enabled if you look at it. You can create new scripts there,too. >>> I like that the most because the scripts are not in the image anymore and the probability to loose them is lower. >>> >>> I have a scripts folder in my home directory (global) and one in the project folder (project specific). And inspectors to bith location are opened by the script that prepares a new image. >>> >>> Norbert >>> >>>> Am 25.11.2017 um 18:34 schrieb Andy Burnett <andy.burnett(a)knowinnovation.com>: >>>> >>>> I have just created a couple of small playground scripts that do some useful data wrangling. The chances are that I will reuse them from time to time, but with tweaks. Does version 6 Have some way to store them? I think I am after a sort of scripts catalogue. >

Dec. 2, 2017