Re: [Pharo-dev] [Mm10s] 2020-02-10
Thanks! On Mon, 10 Feb 2020 at 11:10, teso...@gmail.com wrote: > > It's under construction, but here it is > https://github.com/pharo-project/opensmalltalk-vm/wiki > > On Mon, Feb 10, 2020 at 10:46 AM Alistair Grant wrote: > > > > Hi Pablo, > > > > > > On Mon, 10 Feb 2020 at 10:31, teso...@gmail.com wrote: > > > > > > Monday morning, time for the weekly mail meeting in 10 seconds! > > > (just reply, inserting bullet points) > > > > > > ### Last week: > > > > > > - PharoVM wiki > > > > Is this publicly accessible? Can we have a link? > > > > Thanks! > > Alistair > > > > > -- > Pablo Tesone. > teso...@gmail.com >
Re: [Pharo-dev] [Mm10s] 2020-02-10
Hi Pablo, On Mon, 10 Feb 2020 at 10:31, teso...@gmail.com wrote: > > Monday morning, time for the weekly mail meeting in 10 seconds! > (just reply, inserting bullet points) > > ### Last week: > > - PharoVM wiki Is this publicly accessible? Can we have a link? Thanks! Alistair
Re: [Pharo-dev] New Latest VM - Please Test
Hi Pablo, This VM looks like it will only run with Ubuntu 19.04 or later: $ ./pharo --version /dev/shm/p8/pharo-vm/lib/pharo/5.0-/pharo: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /dev/shm/p8/pharo-vm/lib/pharo/5.0-/pharo) GLIBC 2.29 is delivered with Ubuntu 19.04. Ubuntu 18.04 is the current LTS (GLIBC 2.27), and Ubuntu 16.04 is still supported (GLIBC 2.23), so I'd expect that the VM is linked against 2.23, or at least 2.27. Cheers, Alistair > > Am 19.01.2020 um 19:10 schrieb teso...@gmail.com: > > > > You are right Norbert, sorry I miss the data. > > This is available through zeroConf. > > Doing for example: > > > > wget -O - get.pharo.org/64/70+vmLatest | bash > > wget -O - get.pharo.org/64/80+vmLatest | bash > > > > Cheers, > > Pablo
Re: [Pharo-dev] Fwd: [GitHub] Deprecation Notice
Hi Stef & Guille, I received the same deprecation notice as Stef on 13 December. I've also just seen an `IceGitHubError: Not Found` error: IceGitHubAPI>>responseWithValidationDo: IceGitHubAPI>>contentsWithValidationDo: IceGitHubAPI>>jsonContentsWithValidationDo: IceGitHubAPI>>get: IceGitHubAPI>>getRepository:project: [ ^ IceGitHubAPI new beAnonymous; getRepository: self userName project: self projectName ] in IceTipGitHubRepositoryPanel>>getGitHubRepository in Block: [ ^ IceGitHubAPI new... BlockClosure>>on:do: IceTipGitHubRepositoryPanel>>getGitHubRepository [ | githubRepository | githubRepository := self getGitHubRepository. ... Not sure if it is related or not. Cheers, Alistair On Wed, 22 Jan 2020 at 09:49, Guillermo Polito wrote: > > Did you re-clone your repository? I don’t think so… > Did you create a PR using Pharo’s github integration? > > Those are the only points we use Github’s API :/ > > > El 22 ene 2020, a las 9:13, ducasse escribió: > > > > I was just committing to my pharo fork “….using Zinc HTTP Components 1.0 > > (Pharo/9.0) ...” > > so I do not get fully get it. > > If I’m the only one to receive this mail then this is ok > > > > Guille apparently I used password else it would have failed? Can it be that > > my password is not well set? > > > > I have hte impression that they mean something else. > > > > "We will deprecate basic authentication using password” > > > > S > > > >> On 22 Jan 2020, at 07:47, Guillermo Polito > >> wrote: > >> > >> Hi, > >> > >> I believe that when cloning a repository using the Github tab from > >> iceberg, iceberg makes a request to ask github for that project’s > >> meta-data. > >> This query identifies if the cloned repository is a fork of another > >> repository or not, and in case it is a fork, correctly pre-configure the > >> repository remotes to simplify further operations (such as fetching from > >> upstream, or creating pull requests in-image). > >> > >> If user credentials are not available, such request is anonymous. > >> However, if user credentials **are** available, they are used => this is > >> required for private projects to work. > >> > >> One possible solution would be to add a new kind of credentials > >> Token-based, to existing ones (passwords also used for https, ssh key > >> pairs). > >> > >>> El 22 ene 2020, a las 7:34, Sven Van Caekenberghe escribió: > >>> > >>> We probably have to change something. > >>> > >>> Do you know which operation (GitHub API access from Pharo code) is > >>> responsible for this ? > >>> > On 21 Jan 2020, at 21:05, ducasse wrote: > > what will be the implication? > > > > Begin forwarded message: > > > > From: GitHub > > Subject: [GitHub] Deprecation Notice > > Date: 21 January 2020 at 21:03:28 CET > > To: StéphaneDucasse > > > > Hi @Ducasse, > > > > You recently used a password to access an endpoint through the GitHub > > API using Zinc HTTP Components 1.0 (Pharo/9.0). We will deprecate basic > > authentication using password to this endpoint soon: > > > > https://api.github.com/repositories/169849137 > > > > We recommend using a personal access token (PAT) with the appropriate > > scope to access this endpoint instead. Visit > > https://github.com/settings/tokens for more information. > > > > Thanks, > > The GitHub Team > > > >>> > >>> > >> > >> > > > > > > > > > >
Re: [Pharo-dev] about signal
Hi Eliot, On Sun, 12 Jan 2020 at 18:16, Eliot Miranda wrote: > >> Hi Alastair, >> >> On Jan 12, 2020, at 12:34 AM, Alistair Grant wrote: >> >> I agree with Eliot that changing #processPreemptionYields to true by >> default would be an improvement in Pharo. It would make it easier to >> predict what is happening in a complex environment > > > You mean to write that > > “I agree with Eliot that changing #processPreemptionYields to false by > default would be an improvement in Pharo. It would make it easier to > predict what is happening in a complex environment.” > > Preemption by a higher priority process should not cause a yield. Yes, sorry about that. Cheers, Alistair
Re: [Pharo-dev] about signal
Hi Ben, On Sun, 12 Jan 2020 at 15:26, Ben Coman wrote: > > Now a new consideration for whether Pharo might change the default > processPreemptionYields to false > is ThreadedFFI. Presumably it will be common for a callback to be defined at > same priority as an in-image process. > I can't quite think through the implications myself. > So a question... if a callback is a lower-priority than the current process, > does it wait before grabbing the VM lock (IIUC how that is meant to work)? The version of Threaded FFI I'm using at the moment is about a month old, but assuming nothing has changed... The callback queue is currently run at priority 70 (vs the UI process at 40). The reasoning as explained by Esteban (from memory) is that you may want callbacks to do some small amount of work and respond quickly. > P.S. Now I wonder about the impact of upcoming Idle-VM. Currently > same-priority-processes are effectively round-robin scheduled > because the high priority DelayScheduler triggers often, bumping the current > process to the back of its runQueue. > When it triggers less often, anything relying on this implicit behaviour may > act differently. Another reason to consider #processPreemptionYields set to false :-) Cheers, Alistair
Re: [Pharo-dev] about signal
Hi Stef, On Sun, 12 Jan 2020 at 11:28, ducasse wrote: > > Hi alistair > > > Hi > > I wanted to explain > > | semaphore p1 p2 | > semaphore := Semaphore new. > p1 := [ semaphore wait. >'p1' crTrace ] fork. > > p2 := [semaphore signal. > 'p2' crTrace ] fork. > > displays p2 and p1. > but I would like explain clearly but it depends on the semantics of signal. > > > The way this is phrased seems to imply that 'p2' will always be > displayed before 'p1', however in Pharo this is not guaranteed (when > the processes are at the same priority, as they are this example). > > > No this is not what I implied. > I will reread and rephrase the chapters. > > As Eliot implied in another reply, Pharo has #processPreemptionYields > set to true, which means that any time a higher priority process > preempts, the current process will be moved to the back of the queue. > > > Yes this is explained in the next chapter. > What you should see is that we cannot explain everything in a single chapter. > At least I cannot. Agreed. Maybe just a footnote indicating that process scheduling will be explained in later chapters. > So in the case above, after p2 signals the semaphore, if a timer was > delivered or keystroke pressed, p2 would be suspended and moved to the > back of the queue. When the timer / keystroke / etc. had finished > processing p1 would be at the front of the queue and would complete > first. > > Since time and input events are (for practical purposes) unpredictable > it means that the execution order of processes at a given priority is > also unpredictable. > > While this isn't likely to happen in the example above, I have seen it > regularly with TaskIt and multiple entries being run concurrently. > > I agree with Eliot that changing #processPreemptionYields to true by > default would be an improvement in Pharo. It would make it easier to > predict what is happening in a complex environment. As Sven kindly pointed out, I meant to say set #processPreemptionYields to false. > If this would be that easy. :) > Now what would be a consequence: we should revisit all the processes of the > system > and understand if/where they should yield. Because now there is an implicit > yield. > So in an ideal world the new semantics is probably better. Now are we ready > to get new bugs > and chase them when an old logic like for example an hidden process in > calypso worked > under the assumption that it was implicitly yielding after preemption? > This is the question that we asked ourselves and we do not really know. > So far Pharo worked this way during 12 years with this semantics (I does not > mean that we cannot > change because of our Motto - but the point is to understand the impact and > control). > Contrary to what people may think we are not changing without assessing > impact. > So to us this is not an easy decision (while doing it take one single line of > one assignment). I also wasn't implying that we just go ahead and change it. But if it is a possibility then I'll try changing it in my image and see how it helps with tracking down inter-process interactions that we're currently experiencing, and if it does introduce any showstopper issues. Cheers, Alistair
Re: [Pharo-dev] about signal
Hi Sven, In line below... Cheers, Alistair (on phone) On Sun., 12 Jan. 2020, 13:00 Sven Van Caekenberghe, wrote: > > Hi Alistair, > > > On 12 Jan 2020, at 09:33, Alistair Grant wrote: > > > > > > I agree with Eliot that changing #processPreemptionYields to true by > > default would be an improvement in Pharo. It would make it easier to > > predict what is happening in a complex environment. > > I don't understand, in your second paragraph you say 'Pharo has > #processPreemptionYields set to true' and now you say it should become the > default. Is that already the case or not then ? Oops, typo, sorry. I meant to say 'false'. (I shouldn't ever reply in a hurry). > > > Running the following variant, and then typing in to another window, > > demonstrates the behaviour: > > I am not sure what you want to demonstrate: that it is totally random > depending on external factors ;-) ? If processPreemptionYields false the output should be: ... p2 p1 p2 p1 p2 p1 ... i.e. it is regular. What we're actually seeing is: ... 'p1' 'p2' 'p1' 'p2' 'p2' ... Which showing that p2 might get to signal multiple times before p1 gets to complete a single loop. > Which is pretty bad: how should semaphores be used (safely) ? What are good > examples of real world correct semaphore usage ? Given a set of processes at the same priority the amount of time allocated to any one of the processes is unpredictable. All the semaphore usage is working as described. My point wasn't that the semaphores are being used incorrectly, but that you can't make assumptions about the order in which processes will complete if they are CPU bound. > Right now, all the explanations around scheduling of processes and their > priorities make it seem as if the answer is 'it all depends' and 'there is no > way to be 100% sure what will happen'. The semaphore operations are clear, but which process, within a single process priority, gets the most CPU time is less so. HTH, Alistair
Re: [Pharo-dev] about signal
On Thu, 9 Jan 2020 at 13:01, ducasse wrote: > > Hi > > I wanted to explain > > | semaphore p1 p2 | > semaphore := Semaphore new. > p1 := [ semaphore wait. > 'p1' crTrace ] fork. > > p2 := [semaphore signal. > 'p2' crTrace ] fork. > > displays p2 and p1. > but I would like explain clearly but it depends on the semantics of signal. The way this is phrased seems to imply that 'p2' will always be displayed before 'p1', however in Pharo this is not guaranteed (when the processes are at the same priority, as they are this example). As Eliot implied in another reply, Pharo has #processPreemptionYields set to true, which means that any time a higher priority process preempts, the current process will be moved to the back of the queue. So in the case above, after p2 signals the semaphore, if a timer was delivered or keystroke pressed, p2 would be suspended and moved to the back of the queue. When the timer / keystroke / etc. had finished processing p1 would be at the front of the queue and would complete first. Since time and input events are (for practical purposes) unpredictable it means that the execution order of processes at a given priority is also unpredictable. While this isn't likely to happen in the example above, I have seen it regularly with TaskIt and multiple entries being run concurrently. I agree with Eliot that changing #processPreemptionYields to true by default would be an improvement in Pharo. It would make it easier to predict what is happening in a complex environment. Running the following variant, and then typing in to another window, demonstrates the behaviour: | semaphore p1 p2 | semaphore := Semaphore new. [ 100 timesRepeat: [ p1 := [ | z | semaphore wait. z := SmallInteger maxVal. 1000 timesRepeat: [ z := z + 1 ]. 'p1' crTrace ] fork. p2 := [ | z | 1 second wait. semaphore signal. z := SmallInteger maxVal. 1000 timesRepeat: [ z := z + 1 ]. 'p2' crTrace ] fork. 1 second wait. ] ] fork. The tail of transcript: 'p2' 'p1' 'p1' 'p1' 'p1' 'p2' 'p2' 'p2' 'p1' 'p1' 'p2' 'p1' 'p2' 'p2' 'p1' 'p1' 'p2' 'p1' Cheers, Alistair
Re: [Pharo-dev] BaselineOfZincHTTPComponents>>baseline:
Hi Sven, My apologies for the slow reply. On Mon, 6 Jan 2020 at 14:44, Sven Van Caekenberghe wrote: > > > > > On 6 Jan 2020, at 08:16, Alistair Grant wrote: > > > >> What is your particular problem ? > > > > Pavel did some refactoring in > > https://github.com/pharo-project/pharo/commit/45b7de2b6c901112be04230faba485a2f69ebb1e > > that moved some methods from the FileSystem-Core package to the > > Zinc-Resource-Meta-Core package, and they go missing when loading > > other Zinc packages, e.g. SSO. > > Let's see: this should solve your immediate problem then: > > https://github.com/svenvc/zinc/commit/7d7f55e5654639a81e669b50f196ea4af38b8e61 > > It will fix the issue in Pharo 8. Looks good, thanks! > It will load uncleanly in Pharo 7, but we could do a back port to it if > needed. This doesn't affect us, so no urgency on our side. Thanks again, Alistair
Re: [Pharo-dev] Pharo key features (document)
Hi Pavel, Excellent presentation! Thanks! Alistair On Sun, 5 Jan 2020 at 11:02, Pavel Krivanek wrote: > > Hi, I have created a list of the key Pharo features with some images and > animations that should help to explain to public what is cool on Pharo. It is > based on a list formerly created for a Wikipedia article. > > https://github.com/pavel-krivanek/pharoMaterials/blob/master/features/PharoKeyFeatures.md > > Please look at it to check if something is worth to add or change before we > will try to use it somewhere for real. > > Cheers, > -- Pavel
Re: [Pharo-dev] BaselineOfZincHTTPComponents>>baseline:
Hi Sven, Thanks for your reply. On Sun, 5 Jan 2020 at 14:02, Sven Van Caekenberghe wrote: > > Hi Guys, > > I would obviously want to avoid branches, as long as they are not really > needed. It's not obvious to me. :-) In fact given that Pharo is prepared to break backward compatibility (over time, and in a controlled manner), having a branch per release seems like a good option (not necessarily the only one, of course). > Alistair, looking again at your proposal, I must disagree even harder ;-) > > Right now, (as of 16 days ago), Zinc builds cleanly into Pharo 7 and 8, that > is absolute requirement for me. Of course, it might/will override some > changes in Pharo 8 that were not yet synced back. That is on the todo list. > If one of those changes is absolutely critical to you, we can add it quickly > (syncing the change back, in small chunks). That does require that it also > works on older Pharo versions, that there are comments, tests. Up to now, I > have always managed to make this work. I don't think the change I was proposing would make Zinc any less likely to build cleanly, it should actually increase the likelihood since internal changes to the core Zinc classes that don't affect the interface will not cause problems (in the current version they will). And in fact, it doesn't even introduce (git) branches (despite what I said above) :-) It would mean that there is only one copy of the core classes, which I expect would reduce your workload. > What is your particular problem ? Pavel did some refactoring in https://github.com/pharo-project/pharo/commit/45b7de2b6c901112be04230faba485a2f69ebb1e that moved some methods from the FileSystem-Core package to the Zinc-Resource-Meta-Core package, and they go missing when loading other Zinc packages, e.g. SSO. Thanks! Alistair > Sven > > > On 5 Jan 2020, at 03:14, Tudor Girba wrote: > > > > Hi, > > > > Would introducing branches in Zinc to deal with the different versions of > > Pharo not be an option? > > > > Cheers, > > Doru > > > > > >> On Jan 3, 2020, at 2:48 PM, Alistair Grant wrote: > >> > >> Hi Sven, > >> > >> On Fri, 3 Jan 2020 at 12:36, Sven Van Caekenberghe wrote: > >>> > >>> Alistair, > >>> > >>> Thanks for the write up, it is useful. > >>> > >>> However, the general situation with the relationship between Zinc HTTP > >>> Components and Pharo 8 (or its most recent version in development) is > >>> often difficult. > >>> > >>> For me, as author and maintainer of Zinc HTTP Components is had been very > >>> hard to follow the changes in the latest Pharo and to keep > >>> syncing/merging them back. > >>> > >>> Especially since some changes are not backwards compatible with Pharo 7 > >>> (the latest stable) and the previous ones (let's say 6 and 5). For me and > >>> most users that is unacceptable: HTTP is way too important to not > >>> maintain it properly. The problems with source code file access were an > >>> example of that, luckily Pablo reacted super fast. > >>> > >>> Another point of friction for me are the many cosmetic changes that were > >>> applied, often using automatic means. They do not contribute much > >>> (functionally), but cause lots of trouble (to merge, check, validate). > >>> > >>> Normally, years ago, Zinc was synced into Pharo trunk regularly (like > >>> every 6 months or so). However, this has not happened for a long time. > >>> Why ? Because I have too much work syncing/merging everything back first. > >>> > >>> So I have to put time in this, but it won't happen soon - too much other > >>> work. > >>> > >>> Some more comments inline. > >>> > >>>> On 3 Jan 2020, at 11:34, Alistair Grant wrote: > >>>> > >>>> Hi Sven, > >>>> > >>>> Following on from a discussion I started in Discord development... > >>>> > >>>> Loading Zinc SSO in Pharo 8 currently causes problems because the Zinc > >>>> packages in core Pharo 8 are out of sync with your repository > >>>> (specifically > >>>> https://github.com/pharo-project/pharo/commit/45b7de2b6c901112be04230faba485a2f69ebb1e > >>>> caused problems for me). > >>> > >>> Hmm, I guess I missed that one, but I would of course see it when trying > >>> to merge back. > >>> > >>>> I was able t
Re: [Pharo-dev] BaselineOfZincHTTPComponents>>baseline:
Hi Sven,
On Fri, 3 Jan 2020 at 12:36, Sven Van Caekenberghe wrote:
>
> Alistair,
>
> Thanks for the write up, it is useful.
>
> However, the general situation with the relationship between Zinc HTTP
> Components and Pharo 8 (or its most recent version in development) is often
> difficult.
>
> For me, as author and maintainer of Zinc HTTP Components is had been very
> hard to follow the changes in the latest Pharo and to keep syncing/merging
> them back.
>
> Especially since some changes are not backwards compatible with Pharo 7 (the
> latest stable) and the previous ones (let's say 6 and 5). For me and most
> users that is unacceptable: HTTP is way too important to not maintain it
> properly. The problems with source code file access were an example of that,
> luckily Pablo reacted super fast.
>
> Another point of friction for me are the many cosmetic changes that were
> applied, often using automatic means. They do not contribute much
> (functionally), but cause lots of trouble (to merge, check, validate).
>
> Normally, years ago, Zinc was synced into Pharo trunk regularly (like every 6
> months or so). However, this has not happened for a long time. Why ? Because
> I have too much work syncing/merging everything back first.
>
> So I have to put time in this, but it won't happen soon - too much other work.
>
> Some more comments inline.
>
> > On 3 Jan 2020, at 11:34, Alistair Grant wrote:
> >
> > Hi Sven,
> >
> > Following on from a discussion I started in Discord development...
> >
> > Loading Zinc SSO in Pharo 8 currently causes problems because the Zinc
> > packages in core Pharo 8 are out of sync with your repository
> > (specifically
> > https://github.com/pharo-project/pharo/commit/45b7de2b6c901112be04230faba485a2f69ebb1e
> > caused problems for me).
>
> Hmm, I guess I missed that one, but I would of course see it when trying to
> merge back.
>
> > I was able to resolve the issue by modifying
> > BaselineOfZincHTTPComponents>>baseline: to remove all references to
> > the packages that are now part of core Pharo 8:
> >
> > BaselineOfZincHTTPComponents>>baseline: spec
> >
> >spec for: #common do: [
> >spec baseline: 'NeoJSON' with: [ spec repository:
> > 'github://svenvc/NeoJSON:v17/repository' ].
> >spec baseline: 'XMLParser' with: [ spec repository:
> > 'github://feenkcom/XMLParser:v0.6.1/src' ].
> >spec baseline: 'XMLWriter' with: [ spec repository:
> > 'github://feenkcom/XMLWriter:v0.6.0/src' ].
> >"spec project: 'XML Support' with: [ spec className:
> > 'ConfigurationOfXMLSupport'; repository:
> > 'http://www.squeaksource.com/MetacelloRepository' ]."
> >spec
> >package: 'Zinc-AWS';
> >package: 'Zinc-REST' with: [ spec requires: #('NeoJSON') ];
> >package: 'Zinc-WebSocket-Core';
> >package: 'Zinc-WebSocket-Tests' with: [ spec requires:
> > 'Zinc-WebSocket-Core' ];
> >package: 'Zinc-SSO-OAuth1-Core' with: [ spec requires:
> > #('NeoJSON') ];
> >package: 'Zinc-SSO-OAuth2-Core' with: [ spec requires:
> > #('NeoJSON') ];
> >package: 'Zinc-SSO-OpenID-Core';
> >package: 'Zinc-SSO-Demo' with: [ spec requires:
> > #('Zinc-SSO-OAuth1-Core' 'Zinc-SSO-OAuth2-Core'
> > 'Zinc-SSO-OpenID-Core') ];
> >package: 'Zinc-SSO-OAuth1-Tests' with: [ spec requires:
> > #('Zinc-SSO-OAuth1-Core') ];
> >package: 'Zinc-SSO-OpenID-Tests' with: [ spec requires:
> > #('Zinc-SSO-OpenID-Core') ];
> >package: 'Zinc-WebDAV';
> >package: 'Zinc-WWS-Server';
> >package: 'Zinc-WWS-Client'.
> >spec
> >group: 'AWS' with: #('Zinc-AWS');
> >group: 'WebDAV' with: #('Zinc-WebDAV');
> >group: 'WebSocket' with: #('Zinc-WebSocket-Core'
> > 'Zinc-WebSocket-Tests');
> >group: 'SSO-OAuth1' with: #('Zinc-SSO-OAuth1-Core'
> > 'Zinc-SSO-OAuth1-Tests');
> >group: 'SSO-OAuth2' with: #('Zinc-SSO-OAuth2-Core');
> >group: 'SSO-OpenID' with: #('Zinc-SSO-OpenID-Core'
> > 'Zinc-SSO-OpenID-Tests');
> >group: 'SSO-Demo' with: #('Zinc-SSO-OAuth1-Core'
> > 'Zinc-SSO-OAuth2-Core' 'Zinc-SSO-OpenID-Core');
> >group: 'SSO' with: #('SSO-OAuth1' 'SSO-OAuth2'
> > 'SSO-OpenID' 'SSO-Demo' 'Zinc-SSO-Demo');
> >group: 'WWS' with: #('Zinc-WWS-Server' 'Zinc-WWS-Client');
> >group: 'REST' with: #('Zinc-REST') ]
> >
>
[Pharo-dev] BaselineOfZincHTTPComponents>>baseline:
Hi Sven,
Following on from a discussion I started in Discord development...
Loading Zinc SSO in Pharo 8 currently causes problems because the Zinc
packages in core Pharo 8 are out of sync with your repository
(specifically
https://github.com/pharo-project/pharo/commit/45b7de2b6c901112be04230faba485a2f69ebb1e
caused problems for me).
I was able to resolve the issue by modifying
BaselineOfZincHTTPComponents>>baseline: to remove all references to
the packages that are now part of core Pharo 8:
BaselineOfZincHTTPComponents>>baseline: spec
spec for: #common do: [
spec baseline: 'NeoJSON' with: [ spec repository:
'github://svenvc/NeoJSON:v17/repository' ].
spec baseline: 'XMLParser' with: [ spec repository:
'github://feenkcom/XMLParser:v0.6.1/src' ].
spec baseline: 'XMLWriter' with: [ spec repository:
'github://feenkcom/XMLWriter:v0.6.0/src' ].
"spec project: 'XML Support' with: [ spec className:
'ConfigurationOfXMLSupport'; repository:
'http://www.squeaksource.com/MetacelloRepository' ]."
spec
package: 'Zinc-AWS';
package: 'Zinc-REST' with: [ spec requires: #('NeoJSON') ];
package: 'Zinc-WebSocket-Core';
package: 'Zinc-WebSocket-Tests' with: [ spec requires:
'Zinc-WebSocket-Core' ];
package: 'Zinc-SSO-OAuth1-Core' with: [ spec requires:
#('NeoJSON') ];
package: 'Zinc-SSO-OAuth2-Core' with: [ spec requires:
#('NeoJSON') ];
package: 'Zinc-SSO-OpenID-Core';
package: 'Zinc-SSO-Demo' with: [ spec requires:
#('Zinc-SSO-OAuth1-Core' 'Zinc-SSO-OAuth2-Core'
'Zinc-SSO-OpenID-Core') ];
package: 'Zinc-SSO-OAuth1-Tests' with: [ spec requires:
#('Zinc-SSO-OAuth1-Core') ];
package: 'Zinc-SSO-OpenID-Tests' with: [ spec requires:
#('Zinc-SSO-OpenID-Core') ];
package: 'Zinc-WebDAV';
package: 'Zinc-WWS-Server';
package: 'Zinc-WWS-Client'.
spec
group: 'AWS' with: #('Zinc-AWS');
group: 'WebDAV' with: #('Zinc-WebDAV');
group: 'WebSocket' with: #('Zinc-WebSocket-Core'
'Zinc-WebSocket-Tests');
group: 'SSO-OAuth1' with: #('Zinc-SSO-OAuth1-Core'
'Zinc-SSO-OAuth1-Tests');
group: 'SSO-OAuth2' with: #('Zinc-SSO-OAuth2-Core');
group: 'SSO-OpenID' with: #('Zinc-SSO-OpenID-Core'
'Zinc-SSO-OpenID-Tests');
group: 'SSO-Demo' with: #('Zinc-SSO-OAuth1-Core'
'Zinc-SSO-OAuth2-Core' 'Zinc-SSO-OpenID-Core');
group: 'SSO' with: #('SSO-OAuth1' 'SSO-OAuth2'
'SSO-OpenID' 'SSO-Demo' 'Zinc-SSO-Demo');
group: 'WWS' with: #('Zinc-WWS-Server' 'Zinc-WWS-Client');
group: 'REST' with: #('Zinc-REST') ]
This isn't directly usable by you since it replaces 'XML Support' with
XMLParser and XMLWriter and it would break Pharo 7.
But if we modified it to put in checks for Pharo 7 vs Pharo 8 it would
somewhat future proof the code against changes made in core Pharo 8.
What do you think?
Thanks,
Alistair
Re: [Pharo-dev] Interesting bug or feature in exception processing logic
Hi Denis, Thanks very much for the clarification in your previous email (which I haven't quoted here), I did indeed misunderstand the point you were making. On Thu, 19 Dec 2019 at 19:40, Denis Kudriashov wrote: > > The solution to problem is to resignal UnhandledError instead of simple > signalling. Resignal uses original signalContext as a starting point for > handlers lookup: > > UnhandledError>>signalForException: anError > > ^anError resignalAs: (self new > > exception: anError; > > yourself) > > > I played with some of debugger issues and this code really fixes them. > For example try debug following script in playground: > > [ > self methodWithError > ] on: Error do: [ :e | e logCr. e pass ] > > With error method: > > > Object>>methodWithError > > 1/0 > > Step into #methodWithError and then stepThrough "1/0". > In current image it will hands for a while and then it will open another > debugger with single error item. The current debugger process will be broken. > Now try to apply proposed change for UnhandledError>>signalForException: and > repeat experiment. StepThrough "1/0" will move debugger to ZeroDivide signal > showing correct stack. Confirmed. > Notice that debugging separate "self methodWithError" without outer handler > works correctly in both cases. But you should be in clean stack without > hidden outer handlers. And in Playground or when you use debugIt it is clean. > But you can try in "bad" environment. Execute in browser editor "self halt. > self methodWithError". And in debugger just Step Through #methodWithError. It > will hangs. Proposed change fixes that. > > I will prepare PR with tests. But it would be nice to find other broken > places which will be fixed I thought I'd take a look at VisualWorks (8.3) to see what it does: it has the same behaviour as with your fix above. This opens some other interesting possibilities. Changing some names and reinterpreting your original example: [ result := [ MyResumableError signal ] on: UnhandledError do: [ :e | self doUltimateFallback ] ] on: MyResumableError do: [ :e | e resume: 42 ]. The MyResumableError handler may be way down the call stack. While the code is more than a little contrived, it does demonstrate the possibility of allowing callers to handle exceptions, but then have a fallback if everything else fails. Great detective work! Thanks, Alistair
Re: [Pharo-dev] Interesting bug or feature in exception processing logic
On Wed, 18 Dec 2019 at 23:32, Denis Kudriashov wrote: > > Users of UnhandledError definitely shows that it is a critical bug. > > For example we rely on UnhandledError in Announcer to ensure that all > subscriptions will be processed independently on errors signalled by any of > them: > > ann := Announcer new. > ann when: ValueChanged do: [:ann | 1 logCr. 1/0 ]. > ann when: ValueChanged do: [:ann | 2 logCr. 2/0 ]. > ann when: ValueChanged do: [:ann | 3 logCr. 3/0 ]. > > > ann announce: ValueChanged new > > > It will show 1, 2, 3 in transcript and open 3 debuggers. Each error is > deferred to the background process allowing the delivery to continue: > > AnnouncementSubscription>>deliver: anAnnouncement > > " deliver an announcement to receiver. In case of failure, it will be handled > in separate process" > > > ^ (self handlesAnnouncement: anAnnouncement ) ifTrue: [ > > [action cull: anAnnouncement cull: announcer] > > on: UnhandledError fork: [:ex | ex pass ]] > > > Now if you will try to wrap #announce: into handler block the deliver will be > interrupted by first error: > > [ann announce: ValueChanged new] on: ZeroDivide do: [ :err | err logCr. err > pass ]. > > > It will open single debugger at first handler error. This looks like a bug in AnnouncementSubscription>>deliver:. The exception handler should probably be on Exception since the delivery mechanism just wants to continue and let something else deal with the exception. Cheers, Alistair
Re: [Pharo-dev] Interesting bug or feature in exception processing logic
On Wed, 18 Dec 2019 at 21:45, Denis Kudriashov wrote: > > Following script demonstrates the difference in the error processing logic > when there is an outer handler: > > [ > > [MyTestError signal ] on: UnhandledError do: [ :e | self halt ] > > ] on: MyTestError do: [ :z | z pass] > > > Try it from playground. Second line separately will show the halt while all > together it will stop at MyTestError signal. > > Debugging shows that when the outer handler is processed it sets the handler > context into the exception and it skips the existing handler for > UnhandledError. It isn't skipping the UnhandledError handler. MyTestError isn't a subclass of UnhandledError, it's a subclass of Error, so we expect the first exception handler that is triggered in the code above to be the MyTestError handler. > > The question: is it a feature or a bug? Setting aside whether it is a feature or a bug, it is clearly the defined behaviour. > Think also how following code should work (unrelated to UnhandledError logic): > > [ > > [ 1/0 ] on: MyTestError do: [ :e | self halt ] > > ] on: ZeroDivide do: [ :z | MyTestError signal ] In this case the behaviour should be the same for both the browser and the playground: the 0 divide exception handler catches 1/0 and signals MyTestError, which doesn't have a handler, and a debugger is opened. Cheers, Alistair
Re: [Pharo-dev] Interesting bug or feature in exception processing logic
Hi Denis, This is a really interesting discussion, and I haven't wrapped my head around it properly yet, but one initial observation: On Wed, 18 Dec 2019 at 21:45, Denis Kudriashov wrote: > > Hi. > > I played a bit with exceptions trying to detect that given block will open > the debugger. My idea was to simply catch UnhandledError which normally means > that no outer code handles given error and therefore debugger is appeared. > For my surprise the following example works from playground but not from the > browser editor: > > > [MyTestError signal ] on: UnhandledError do: [ :e | self halt ] > > > In playground you will see the halt. But from the browser the debugger will > show MyTestError. > > After breaking my head I found that there is a difference how scripts are > executed in those tools. In Playground it is a deferred action. But in the > browser it is evaluated as a deep event processing code (keymap processing) > and there is an outer error handler (on: Error do: ) which does some work and > passes the exception further (err pass). I think the difference here is that in the playground 'self' is nil, while in the browser 'self' is the class being inspected. UndefinedObject>>handleSignal: tells the exception to execute its #defaultAction, which is to signal the UnhandledError, and thus it evaluates the block. One other thing to keep in mind, UnhandledError is a subclass of Exception. It will only catch signals of itself, unlike Error or Exception, which will catch all their subclasses. So 'MyTestError signal' can only be caught if something catches it and then signals UnhandledError. In this case it is the #defaultAction. HTH, Alistair
Re: [Pharo-dev] VM crash investigations
Hi Stef, On Mon, 25 Nov 2019 at 21:36, Stéphane Ducasse wrote: > > Did you read that paper https://hal.inria.fr/hal-01152610 ? > Because may be it can give you ideas of possible problems. That, and Eliot's blog posts, and class comments of SpurMemoryManager, SpurPlanningCompactor, etc. (not that I understood it all) :-) > Pablo is on vacation until next monday. Guille working wednesday, thursday > and friday afternoons OK, thanks. Cheers, Alistair
Re: [Pharo-dev] ZnBufferedReadWriteStream vs SourceFileBufferedReadWriteStream/SourceFileCharacterReadWriteStream
Hi Sven, On Fri., 11 Oct. 2019, 15:05 Sven Van Caekenberghe, wrote: > > > > On 11 Oct 2019, at 14:49, Cyril Ferlicot > wrote: > > > > On Fri, Oct 11, 2019 at 2:32 PM Sven Van Caekenberghe > wrote: > >> > >> I also do not understand how this was done in Pharo 7 *before* it was > finalised/fully debugged in Pharo 8. > >> > >> Back-porting must be done very carefully. > >> > > > > Hi Sven, > > > > One thing that must be know is that everything going in the Pharo 7 > > branch is not released directly. > > The changes you talk about are in no release currently. A release is > > launched manually currently when important changes are backported and > > stabilized. > > Hmm, OK, the /64/70+vm zeroconf version is indeed Pharo 7.0.4 build: 168, > commit: ccd1f64 which does still load Zn correctly, I just tested that > again. > > But how come some users are reporting problems then ? Is there a way they > can access that unreleased version, maybe via the launcher ? > Exactly... The launcher appears to download the latest snapshot. Cheers, Alistair (on phone) > > >
Re: [Pharo-dev] ZincHTTPComponents SSO breaks ZnBufferedReadWriteStream
Just for reference, some of the PRs associated with the issue: - https://github.com/pharo-project/pharo/pull/4726 - https://github.com/pharo-project/pharo/pull/4739 - https://github.com/pharo-project/pharo/pull/4752 On Sat, 28 Sep 2019 at 09:45, Alistair Grant wrote: > > Hi Sven, > > Executing: > > Metacello new > baseline: 'ZincHTTPComponents'; > repository: 'github://svenvc/zinc/repository'; > load: #(SSO) > > In recent Pharo 8 images breaks ZnBufferedReadWriteStream by > redefining the class to remove many of the instance variables. > > I guess this is due to changes to ZnBufferedReadWriteStream made in > the last few days, but the result is that the image is unusable (all > access to the changes file cause exceptions). > > Where should an issue be raised? > > Thanks, > Alistair > > Pharo8.0.0 > Build information: > Pharo-8.0.0+build.798.sha.ae566532ed60b60d669aff37d4d38b86241a7c9e (64 > Bit) > Ubuntu 16.04
Re: [Pharo-dev] ZincHTTPComponents SSO breaks ZnBufferedReadWriteStream
Hi Stef, Just evaluate the Metacello expression from my original email :-) You'll get multiple debuggers open and the image will lock up. A user interrupt will get input working again, but source code is no longer available in the system browser. You'll have to kill the process externally as it fails while trying to exit. Cheers, Alistair On Sat, 28 Sep 2019 at 09:51, ducasse wrote: > > Hello Alistair > > Here :) > I’m sure that we will fix it. > Do you have a test or something to get the problem. > > S. > > > On 28 Sep 2019, at 09:45, Alistair Grant wrote: > > > > Hi Sven, > > > > Executing: > > > > Metacello new > >baseline: 'ZincHTTPComponents'; > >repository: 'github://svenvc/zinc/repository'; > >load: #(SSO) > > > > In recent Pharo 8 images breaks ZnBufferedReadWriteStream by > > redefining the class to remove many of the instance variables. > > > > I guess this is due to changes to ZnBufferedReadWriteStream made in > > the last few days, but the result is that the image is unusable (all > > access to the changes file cause exceptions). > > > > Where should an issue be raised? > > > > Thanks, > > Alistair > > > > Pharo8.0.0 > > Build information: > > Pharo-8.0.0+build.798.sha.ae566532ed60b60d669aff37d4d38b86241a7c9e (64 > > Bit) > > Ubuntu 16.04 > > > > >
[Pharo-dev] ZincHTTPComponents SSO breaks ZnBufferedReadWriteStream
Hi Sven, Executing: Metacello new baseline: 'ZincHTTPComponents'; repository: 'github://svenvc/zinc/repository'; load: #(SSO) In recent Pharo 8 images breaks ZnBufferedReadWriteStream by redefining the class to remove many of the instance variables. I guess this is due to changes to ZnBufferedReadWriteStream made in the last few days, but the result is that the image is unusable (all access to the changes file cause exceptions). Where should an issue be raised? Thanks, Alistair Pharo8.0.0 Build information: Pharo-8.0.0+build.798.sha.ae566532ed60b60d669aff37d4d38b86241a7c9e (64 Bit) Ubuntu 16.04
Re: [Pharo-dev] Fuel Not Serializing Stateful Traits
Hi Sean, On Mon, 23 Sep 2019 at 23:37, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote > > I see commit 1dd... back in March 2018 says it should work > > Investigating a bit further, maybe the problem is in Pharo, because another > test in Pharo 8 didn't show the issue. instanceVariableNamesDo: doesn't seem > to have changed, so I guess it's deeper. Any ideas? Otherwise I'll have to > rollback my stateful trait usage until Pharo 8! This might provide a bit more info: https://github.com/pharo-project/pharo/issues/3546 Cheers, Alistair
Re: [Pharo-dev] TraitedMetaclass / Behaviour bug?
Hi Guille, On Wed, 18 Sep 2019 at 15:22, Guillermo Polito wrote: > > > > El 18 sept 2019, a las 15:05, Alistair Grant escribió: > > > [snip/] > > From what you've written above (and below), the two dictionaries > should always have the same instance of CompiledMethod so it shouldn't > matter where it comes from. > > > Just for the record, yes and no :). > > With the new trait implementation, we have actually a modular MOP. > All classes (whether traited or not) understand: > - #localMethods => returning the methods as they are implemented in the > class > - #methods => returning the actual methods executed by the VM > > For normal classes, #localMethods is defined as follows: > > localMethods > ^ self methods > > And methods understand > - #origin => where that method is actually defined > For example, in a traited class a lookup should be done in the trait > composition, otherwise is the class where the method is installed. > > Tools should work against #localMethods and #origin, which hide how the > actual implementation stores the things :). > We already had in the past a lot of tools that hardcoded/duplicated the > internals of Traits for example. > > The other advantage of this is that, imagine you want to extend Pharo with: > - multimethods => localMethods will have a single multi-method > implementation, and the implementation side will contain maybe an expanded > version with type checks or even one method per type combination > - optional parameters => a single method with many parameters should be > expanded to many methods with less parameters + default values > > The idea is that tools do not hardcode the implementation details of these > extensions, so the public API is #localMethods and #origin :) > Of course, one could design a tool showing #methods, which will show the > low-level view of classes. Thanks for the clarification, that makes sense and will help with tracking this further. > > I haven't looked at this, but what I saw was the localMethods was > > correct and the methodDict was old: > > > > Redefine a base system method (LGitCommit>>commit_author:) using an > > extension method resulted in methodDict containing the original > > definition and the localMethods containing the overridden method. > > What I would expect is that the overridden method is what is used > > everywhere. > > > > I'm not sure if this is related to UFFI or not. > > > Pablo tracked this down to possibly > > FFIMethodRegistry >> removeMethod: aMethod > > aMethod methodClass methodDict > at: aMethod selector > put: (aMethod propertyValueAt: #ffiNonCompiledMethod) That does look bad :-) Using the test class included below: MethodDictionaryConsistencyTest new inconsistentMethodDefinitions answers a collection of 240 methods where methodDict and localMethods aren't the same instance. All of the methods class names begin with 'LGit' :-) There may still be one more bug involved since the scenario I mentioned above regarding Iceberg and extension methods doesn't seem to fit the FFI description (it calls an ffi method, but isn't one itself). Thanks, Alistair MethodDictionaryConsistencyTest.st Description: Binary data
Re: [Pharo-dev] TraitedMetaclass / Behaviour bug?
Inline below... Cheers, Alistair (on phone) On Wed., 18 Sep. 2019, 15:05 Guillermo Polito, wrote: > About bug1) I’ve found that Calypso query scopes use sometimes #methods > and sometimes #localMethods > > ClyLocalClassScope >> methodsDo: aBlock > > self classesDo: [ :eachClass | > self metaLevelsOf: eachClass do: [ :concreteMetaLevelClass > | > concreteMetaLevelClass methods do: aBlock ] ] > > > ClyClassHierarchyScope >> methodsDo: aBlock > > self classesDo: [ :eachClass | > self metaLevelsOf: eachClass do: [ :concreteMetaLevelClass > | > concreteMetaLevelClass methods do: aBlock ] ] > > ClyPackageScope >> methodsDo: aBlock > self classesDo: [:class | > class localMethods do: aBlock. > class classSide localMethods do: aBlock]. > > self packagesDo: [ :package | > package extensionMethods do: aBlock ] > > ClySystemEnvironmentScope >> methodsDo: aBlock > > self classesDo: [:class | > class instanceSide localMethods do: aBlock. > class classSide localMethods do: aBlock] > > We should get an homogeneous version of this. > > Pablo is checking the UFFI compilation now :) > Right. I wrote that it shouldn't matter whether methodDict or local methods is used, but I agree that there should be a single accessor that is used everywhere. Thanks! Alistair > > > El 18 sept 2019, a las 14:20, Alistair Grant > escribió: > > > > P.S. Two implications of this: > > > > 1. The code you're looking at may not be the code that is executed. > > If in doubt, use the standard System Browser (not senders, > > implementers, etc.). > > 2. Iceberg may not be loading extension methods that override an > > existing method correctly, so the old version is left as the > > executable code. There may be happening in other situations as well, > > I haven't checked. > > > > Thanks, > > Alistair > > > > On Wed, 18 Sep 2019 at 11:04, Alistair Grant > wrote: > >> > >> Hi Everyone, > >> > >> TraitedMetaclass stores methods in two different instance variables: > >> > >> - methodDict (inherited from Behavior) > >> - localMethods > >> > >> And the same method can be different in each dictionary. > >> > >> Different browsers show different versions, i.e.: > >> > >> - The System Browser uses the method in methodDict. > >> - Calypso's "Senders of" browser uses localMethods. > >> - The Iceberg versions browser uses localMethods. > >> > >> It appears that the method in methodDict is the one that is actually > >> used when a message is sent, but it would be nice to get confirmation. > >> > >> To reproduce this in a clean Pharo 8 image: > >> > >> - Open the System Browser on LGitBuf class>>signature_free: (the > >> methodDict version). > >> - Open the system browser on TLGitCalloutTrait>>call:options: and then > >> press "Senders". The resulting window will include LGitBuf > >> class>>signature_free:, but the localMethods version. > >> > >> In this example, #signature_free: isn't defined by the trait, and > >> isn't overwritten, so I would expect that the method in both > >> dictionaries should be the same or it should only be in one > >> dictionary. > >> > >> Can someone say what the intended behaviour is? > >> > >> Thanks, > >> Alistair > > > > >
Re: [Pharo-dev] TraitedMetaclass / Behaviour bug?
Hi Guille, Replies inline... On Wed, 18 Sep 2019 at 14:44, Guillermo Polito wrote: > > Hi Alistair, > > we are checking this with Pablo here, some questions inline > > > El 18 sept 2019, a las 11:04, Alistair Grant > > escribió: > > > > Hi Everyone, > > > > TraitedMetaclass stores methods in two different instance variables: > > > > - methodDict (inherited from Behavior) > > - localMethods > > > > And the same method can be different in each dictionary. > > Yes, trais actually work by flattening the methods of traits into the user > class. > - localMethods defines the methods actually defined in the class > - methodDict has the raw low-level flattened version the VM uses for the > lookup So methodDict and localMethods should always contain the same instance of CompiledMethod for a given selector, right? > > > > > Different browsers show different versions, i.e.: > > > > - The System Browser uses the method in methodDict. > > Which is this System browser? Calypso system browser? Yep, as in World Menu -> Tools -> System Browser > > - Calypso's "Senders of" browser uses localMethods. > > and this is Calypso senders, right? Yes, pressing the "Senders" button from the System Browser (Calypso). > > - The Iceberg versions browser uses localMethods. > > > > It appears that the method in methodDict is the one that is actually > > used when a message is sent, but it would be nice to get confirmation. > > > > To reproduce this in a clean Pharo 8 image: > > > > - Open the System Browser on LGitBuf class>>signature_free: (the > > methodDict version). > > - Open the system browser on TLGitCalloutTrait>>call:options: and then > > press "Senders". The resulting window will include LGitBuf > > class>>signature_free:, but the localMethods version. > > > > In this example, #signature_free: isn't defined by the trait, and > > isn't overwritten, so I would expect that the method in both > > dictionaries should be the same or it should only be in one > > dictionary. > > > > Can someone say what the intended behaviour is? > > We are tracking this, it seems you have found two bugs :D. > > 1st bug) Calypso and the senders/implementors should be in sync and show the > same (always the local methods for traited classes) >From what you've written above (and below), the two dictionaries should always have the same instance of CompiledMethod so it shouldn't matter where it comes from. > Moreover, (I’m confirming this with Pablo on line right now) the local > methods dictionary should be just a subset of the method dictionary. > In other words, the invariant is that methods in localMethods should be > included in the methoddict, they should not differ as they are differing > there. > > 2nd bug) UFFI? seems to be messing with this invariant :) > > When a UFFI binding is executed for the very first time, the ffi call > definition gets compiled and a new compiled method is generated performing > that call. > When a session finishes (the image stops/restarts) ffi bindings are reset > (because their compilation is platform dependent). > > What we are seeing there is that somehow UFFI managed to reset a binding > method and put a wrong one in the local method > > I’ve seen this bug before but never got the insight of what was producing it > (neither put too much time to dig on it either :P). > Another possibility is that the culprit are the LibGit bindings, which extend > UFFI binding compilation. I haven't looked at this, but what I saw was the localMethods was correct and the methodDict was old: Redefine a base system method (LGitCommit>>commit_author:) using an extension method resulted in methodDict containing the original definition and the localMethods containing the overridden method. What I would expect is that the overridden method is what is used everywhere. I'm not sure if this is related to UFFI or not. I'm on Discord if you'd like to chat real-time (back around 15:25). Thanks! Alistair
Re: [Pharo-dev] TraitedMetaclass / Behaviour bug?
P.S. Two implications of this: 1. The code you're looking at may not be the code that is executed. If in doubt, use the standard System Browser (not senders, implementers, etc.). 2. Iceberg may not be loading extension methods that override an existing method correctly, so the old version is left as the executable code. There may be happening in other situations as well, I haven't checked. Thanks, Alistair On Wed, 18 Sep 2019 at 11:04, Alistair Grant wrote: > > Hi Everyone, > > TraitedMetaclass stores methods in two different instance variables: > > - methodDict (inherited from Behavior) > - localMethods > > And the same method can be different in each dictionary. > > Different browsers show different versions, i.e.: > > - The System Browser uses the method in methodDict. > - Calypso's "Senders of" browser uses localMethods. > - The Iceberg versions browser uses localMethods. > > It appears that the method in methodDict is the one that is actually > used when a message is sent, but it would be nice to get confirmation. > > To reproduce this in a clean Pharo 8 image: > > - Open the System Browser on LGitBuf class>>signature_free: (the > methodDict version). > - Open the system browser on TLGitCalloutTrait>>call:options: and then > press "Senders". The resulting window will include LGitBuf > class>>signature_free:, but the localMethods version. > > In this example, #signature_free: isn't defined by the trait, and > isn't overwritten, so I would expect that the method in both > dictionaries should be the same or it should only be in one > dictionary. > > Can someone say what the intended behaviour is? > > Thanks, > Alistair
[Pharo-dev] TraitedMetaclass / Behaviour bug?
Hi Everyone, TraitedMetaclass stores methods in two different instance variables: - methodDict (inherited from Behavior) - localMethods And the same method can be different in each dictionary. Different browsers show different versions, i.e.: - The System Browser uses the method in methodDict. - Calypso's "Senders of" browser uses localMethods. - The Iceberg versions browser uses localMethods. It appears that the method in methodDict is the one that is actually used when a message is sent, but it would be nice to get confirmation. To reproduce this in a clean Pharo 8 image: - Open the System Browser on LGitBuf class>>signature_free: (the methodDict version). - Open the system browser on TLGitCalloutTrait>>call:options: and then press "Senders". The resulting window will include LGitBuf class>>signature_free:, but the localMethods version. In this example, #signature_free: isn't defined by the trait, and isn't overwritten, so I would expect that the method in both dictionaries should be the same or it should only be in one dictionary. Can someone say what the intended behaviour is? Thanks, Alistair
Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?
I should have looked before typing :-) My memory of the FileSystemDirectoryEntry hierarchy was wrong, so it isn't as simple as I thought. But I'll still take a look at this. Cheers, Alistair On Tue, 6 Aug 2019 at 12:19, ducasse wrote: > > Ok then this is good. > > > > > Something like this will work: > > > > aDirectoryFileReference entries select: [ :each | each isHidden ] > > > > Cheers, > > Alistair > > > > >
Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?
On Tue, 6 Aug 2019 at 12:05, ducasse wrote: > > > > > On 6 Aug 2019, at 12:01, Alistair Grant wrote: > > > > Hi Stef, > > > > On Fri, 2 Aug 2019 at 09:19, ducasse wrote: > >> > >> It would be good to encapsulate this behavior may be with double dispatch > >> with the platform. > >> Else clients end up to be forced to check. > > > > Why do you think this might need double dispatch? > > I thought that it is specific and different on each platform. > > > > > My idea was that it can be added to FileSystemDirectoryEntry and > > subclasses (FileReference is already fairly heavily loaded, and should > > be kept to the basic, platform common attributes). The main reason I > > didn't was because most of the attributes are windows specific, and I > > was focusing on getting the basic behaviour working and integrated. > > > > Adding just this attribute is fairly simple. I'll submit a PR soon(ish). > > You see as a user I would like to be able to write. > > aFileReference allHiddenFiles > > and do not care that I’m on windows or mac but this is probably too naive. Something like this will work: aDirectoryFileReference entries select: [ :each | each isHidden ] Cheers, Alistair
Re: [Pharo-dev] [FileReference] why this class don't provide a method isAHiddenFile ?
On Thu, 1 Aug 2019 at 20:51, Peter Uhnak wrote: > > I imagine because it is quite a rare edge-case use and is not easy to > implement: > - for Linux you check for dot > - for Windows you need to either modify the VM (see File > class>>lookupDirectory:filename: to provide more information), or directly > use WinAPI from Pharo to retrieve the hidden file attribute > - for MacOS it is my understanding that you need to do both of the above and > then some > > Peter > As Peter wrote, this hasn't been requested much, but... In Pharo 8: (aFileReference entry statAttributes at: 13) anyMask: 16r2 Will answer a boolean indicating whether it is hidden or not (only on Windows). "aFileReference entry statAttributes at: 13" is the WIN32_FILE_ATTRIBUTE_DATA: https://docs.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants HTH, Alistair
Re: [Pharo-dev] Pharo process scheduling
Hi Henrik, I have to admit that I'm having a bit of trouble following what you're saying, so I'll make a few comments that I hope are helpful... Just to start off, my understanding of the term "pre-emptive, cooperative" processing is: - a higher priority process will interrupt a lower priority process and run until it voluntarily waits (or is suspended or terminated). - "cooperative" should be read as "unless the processes cooperate, one bad actor can stop anyone else from getting the CPU". On Tue, Jul 30, 2019 at 05:32:13AM -0500, Henrik Sperre Johansen wrote: > Alistair Grant wrote > > The following produces what I was expecting: > > > > | p x a index first | > > > > Smalltalk vm processPreemptionYields: false. > > > > > > Thanks again! > > Alistair > > Well... what your example shows, is that with processes > p50 (pri50) periodic, becoming runnable in time slot 2) > p40.1 (taking 3 time slots to complete) > p40.2 (taking 3 time slots to complete) > > When preemption yields, you get processor time allocations like this: > [p40.1][p50][p40.2][p40.1][p40.2][p40.1][p40.2] I think this might be demonstrating an incorrect expectation on your part. Your use of the term "time slot" seems to imply that, within a given process priority, each process can expect roughly equal CPU time. However that isn't what is implied. With processPreemptionYields: true *any* higher priority process becoming runnable will cause the currently executing process to be moved to the back of the queue. In practice, where processes are running at a priority of less than 60, this means that with every mouse move, keyboard input, timer event, etc., the active process will be moved to the back of the queue. The amount of time allocated to each process is effectively random. So in the above example, assuming that the p50 process only becomes runnable once, and no other high priority process becomes runnable, we can expect: [p40.1][p50][p40.2][p40.1] > With preemption NOT yielding, you get processor time allocations like this: > [p40.1][p50][p40.1][p40.1][p40.2][p40.2][p40.2] I'd expect: [p40.1][p50][p40.1][p40.2] (running the example code used earlier in VW also supports this) > Which clearly contradicts the statements in the linked post > "Nothing changes within priorities. I haven't looked up the original post, but it seems out of context. > What the setting controls is what > happens when a process is preempted by a higher-priority process. The old > code did an implicit yield of the preempted process, destroying the > guarantee of cooperative scheduling within a priority." This matches my understanding (remember that "cooperative" means that a process has to voluntarily relinquish the CPU). > Which (to me) would imply slot allocations when not yielding would be like > this: > [p40.1][p50][p40.1][p40.2][p40.1][p40.2][p40.2] > > Maybe it's what is intended and the statements are inaccurate, or Pharo is > lacking some related changes, but it doesn't make for a good experience when > you have multiple processes requiring "real-time" execution running at the > same priority if you have to add explicit Processor yield's everywhere. Actually, this matches exactly my understanding of real-time processing. E.g. in VAX/VMS there were two tiers of process priority: - the low priority tier, e.g. 1 - 40 (I can't remember the actual numbers) were time sliced. So if multiple processes were at the same priority, they could expect roughly equal amounts of CPU time. - the high priority tier, e.g. 41 - 80, were cooperative. So if multiple processes were at the same priority, the second one had to wait for the first to voluntarily give up the CPU. The expectation in this case was that any time a real-time process had work to do, the time required would be reasonably short, and that it was important to let it have the CPU until it had completed that work. On Tue, Jul 30, 2019 at 05:53:52AM -0500, Henrik Sperre Johansen wrote: > Henrik Sperre Johansen wrote > > Which clearly contradicts the statements in the linked post > > "Nothing changes within priorities. What the setting controls is what > > happens when a process is preempted by a higher-priority process. The old > > code did an implicit yield of the preempted process, destroying the > > guarantee of cooperative scheduling within a priority." > > Or it could mean the understanding was that processes at the same priority > would have to explicitly yield for other processes of the same priority to > run also with preemptionyields = true. > ... which, seems to be true. > > It's just that we never see that in practice, even running at pri 80, as the > Dela
Re: [Pharo-dev] Pharo process scheduling
For the record, a more detailed discussion of the same thing: http://forum.world.st/The-Trunk-Kernel-mt-1009-mcz-td4887889.html Thanks to Andrei Chis for the link (offline). Cheers Alistair On Mon, 29 Jul 2019 at 14:00, Alistair Grant wrote: > > Hi Henrik, > > Thanks very much for your reply. > > > You wrote: > | p x a index first | > > p := 35. > a := Array new: 21. > index := 1. > first := nil. > [ 1 to: 10 do: [ :i | > [ > first == nil ifTrue: [ first := i. > a at: 21 put: first. ]. > a at: index put: i. > index := index + 1. > x := 0. > 3 timesRepeat: [ x := x + 1 ]. > a at: index put: i. > index := index + 1. ] forkAt: p named: 'Proc', i asString ]. > first == nil ifTrue: [ first := -1. > a at: 21 put: first. ]. > ] forkAt: p+1. > a. > > > Good point, I didn't think this one through properly. And changing > both #fork:'s to priority 80 produces the expected: > > #(1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 -1) > > So far, so good. > > > > > when a process is suspended, it is put to the back of the thread > > And this was my misunderstanding. I thought that preempting a process > left it at the front of the queue (for its priority). > > The following produces what I was expecting: > > > | p x a index first | > > Smalltalk vm processPreemptionYields: false. > p := 20. > a := Array new: 21. > index := 1. > first := nil. > [ 1 to: 10 do: [ :i | > [ > first == nil ifTrue: [ first := i. > a at: 21 put: first. ]. > a at: index put: i. > index := index + 1. > x := 0. > 3 timesRepeat: [ x := x + 1 ]. > a at: index put: i. > index := index + 1. ] forkAt: p named: 'Proc', i asString ]. > first == nil ifTrue: [ first := -1. > a at: 21 put: first. ]. > ] forkAt: p+1. > a. > > > > Thanks again! > Alistair > > On Mon, 29 Jul 2019 at 12:53, Henrik Sperre Johansen > wrote: > > > > Henrik Sperre Johansen wrote > > > If you remove the suspension point (technically, at:put: is also a > > > suspension point, but let's assume it won't be far enough along in the > > > time > > > slice when the first at:put: happens), and set p high enough that the > > > process won't be interrupted by UI thread (when a process is suspended, it > > > is put to the back of the thread, so you'd still see 1 2 3 4 5 6 7 8 9 > > > 10), > > > you get the behaviour you originally expected > > > > ( 1 1 2 3 3 4 5 5 6 7 7 8 9 9 10 2 4 6 8 10 -1 ) > > well, close enough, anyways ;) > > > > Cheers, > > Henry > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >
Re: [Pharo-dev] Pharo process scheduling
Hi Henrik, Thanks very much for your reply. You wrote: | p x a index first | p := 35. a := Array new: 21. index := 1. first := nil. [ 1 to: 10 do: [ :i | [ first == nil ifTrue: [ first := i. a at: 21 put: first. ]. a at: index put: i. index := index + 1. x := 0. 3 timesRepeat: [ x := x + 1 ]. a at: index put: i. index := index + 1. ] forkAt: p named: 'Proc', i asString ]. first == nil ifTrue: [ first := -1. a at: 21 put: first. ]. ] forkAt: p+1. a. Good point, I didn't think this one through properly. And changing both #fork:'s to priority 80 produces the expected: #(1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 -1) So far, so good. > when a process is suspended, it is put to the back of the thread And this was my misunderstanding. I thought that preempting a process left it at the front of the queue (for its priority). The following produces what I was expecting: | p x a index first | Smalltalk vm processPreemptionYields: false. p := 20. a := Array new: 21. index := 1. first := nil. [ 1 to: 10 do: [ :i | [ first == nil ifTrue: [ first := i. a at: 21 put: first. ]. a at: index put: i. index := index + 1. x := 0. 3 timesRepeat: [ x := x + 1 ]. a at: index put: i. index := index + 1. ] forkAt: p named: 'Proc', i asString ]. first == nil ifTrue: [ first := -1. a at: 21 put: first. ]. ] forkAt: p+1. a. Thanks again! Alistair On Mon, 29 Jul 2019 at 12:53, Henrik Sperre Johansen wrote: > > Henrik Sperre Johansen wrote > > If you remove the suspension point (technically, at:put: is also a > > suspension point, but let's assume it won't be far enough along in the > > time > > slice when the first at:put: happens), and set p high enough that the > > process won't be interrupted by UI thread (when a process is suspended, it > > is put to the back of the thread, so you'd still see 1 2 3 4 5 6 7 8 9 > > 10), > > you get the behaviour you originally expected > > ( 1 1 2 3 3 4 5 5 6 7 7 8 9 9 10 2 4 6 8 10 -1 ) > well, close enough, anyways ;) > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >
[Pharo-dev] Pharo process scheduling
Hi Everyone, I'm trying to get a better grip on process scheduling in Pharo but don't understand the behaviour I'm seeing. My understanding is that the VM (which does the real work of scheduling the processes) is a pre-emptive co-operative model, meaning: - Higher priority processes are always scheduled ahead of lower priority processes. - Processes at the same priority get the CPU until something is done to explicitly stop processing, e.g.: -- terminate the process, wait on semaphore (I/O, timer, mutex, etc.), #yield the processor But given the following: | p x a index | p := 35. a := Array new: 20. index := 1. [ 1 to: 10 do: [ :i | [ a at: index put: i. index := index + 1. x := 0. 3 timesRepeat: [ x := x + 1 ]. a at: index put: i. index := index + 1. ] forkAt: p named: 'Proc', i asString ]. ] forkAt: p+1. a. The code above was written to be as simple as possible (it isn't going to be creating streams, have semaphores etc. called somewhere deep within). The 3 number was manually determined as something that will run for a few seconds on my laptop. Since the forking process is higher priority than the 10 worker processes, I expect that all 10 processes will be created before the first gets any CPU, and they will then be executed in order (since there is nothing obvious to cause a context switch), and the results to be: #(1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10) But it appears that each process gets some time as soon as it is forked despite being a lower priority than the forking process, and then the order becomes non-deterministic: #(1 2 3 4 5 6 7 8 9 10 7 10 9 1 2 3 4 5 6 8) #(1 2 3 4 5 6 7 8 9 10 5 9 2 10 4 7 1 6 3 8) #(1 2 3 4 5 6 7 8 9 10 6 1 8 9 3 4 7 10 5 2) Changing p := 45 (so it is higher priority than the morphic UI process) doesn't have any effect. Can someone explain what I'm missing in my understanding? Thanks! Alistair
[Pharo-dev] linux minheadless pharo vm builds itimer or heartbeat?
Hi All,
Are Pharo linux minheadless builds itimer or threaded heartbeat?
(all the listings below are extracts, not the complete file / page)
The file list on bintray suggests that they are itimer:
https://bintray.com/opensmalltalk/vm/cog/201907112020#files
pharo.cog.spur+sdl2-cmake-minhdls_linux64x64_itimer_201907112020.tar.gz
6 days ago 4.23 MB
pharo.cog.spur-cmake-minhdls_linux64x64_itimer_201907112020.tar.gz 6
days ago 4.22 MB
While travis indicates that only threaded heartbeat versions are built:
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/553922116
Setting environment variables from .travis.yml
$ export ARCH="linux64x64"
$ export FLAVOR="pharo.cog.spur"
$ export CPU_ARCH="x64"
$ export HEARTBEAT="threaded"
$ export BUILD_WITH_CMAKE="yes"
.travis.yml agrees with the travis output:
- stage: "Minheadless CMake builds"
- env: ARCH="linux32x86" FLAVOR="pharo.cog.spur" CPU_ARCH="x86"
HEARTBEAT="threaded" BUILD_WITH_CMAKE="yes"
- env: ARCH="linux64x64" FLAVOR="pharo.cog.spur" CPU_ARCH="x64"
HEARTBEAT="threaded" BUILD_WITH_CMAKE="yes"
And pack-vm.sh seems to be doing the right thing when determining how
to name the archive:
for dir in */; do
if [[ "${ARCH}" == *"ARM"* || "${dir}" == *"ht/" ]]; then
name="${IDENTIFIER}"
else
name="${IDENTIFIER_ITIMER}"
fi
Unfortunately figuring out which VM is being used isn't helped by the
fact that "pharo --version" doesn't work with minheadless:
$ ./pharo --version
Opening Image: --version
Opening Image: No such file or directory
Error opening image file: --version
Thanks,
Alistair
Re: [Pharo-dev] Default line endings while writing to a file stream
Hi Ben, On Fri, 31 May 2019 at 07:08, Ben Coman wrote: > > > I'm on Windows wanting to write a text file with LF endings. > The code developed on Linux is thus... > (destinationDirectory / 'README.md') ensureCreateFile > writeStreamDo: [ :stream | stream nextPutAll: class comment ] I've come across this so many times that I always add a couple of methods to my image: ZnEncodedStream>>asNewLineStream "Answer the receiver wrapped with a ZnNewLineWriterStream" ^ZnNewLineWriterStream on: self! ! ZnNewLineWriterStream>>asNewLineStream "Answer the receiver wrapped with a ZnNewLineWriterStream" ^self! ! You could then modify the example above to be: stream asNewLineStream forLf nextPutAll: class comment Cheers, Alistair > and I am stuck with CR line endings. > The specific symptom is that it screws `git diff` > Here is a simple experiment... > testfile := 'README.md' asFileReference. > testfile ensureCreateFile writeStreamDo: [ :stream | > stream nextPutAll: 'aa > bb' ]. > testfile binaryReadStream contents at: 3 "==> Character cr " > > I think its safe to assume on Linux that will result in "==> Character lf " > but can someone please confirm? > > So my issue is that I've got > #ensureCreateFile - returns a FileReference > and > :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream > wrapping BinaryFileStream. > > and neither seem to have an easily accessible defaultLineEnding setting. > Indeed, line endings are not a property of FileReference > and Binary & Characters have nothing to do with line endings, > and questionable if Buffering is related. > > Its more a property of a File, but IIUC that is being deprecated (??) > > MultiByteFileStream has #lineEndConvention: > but IIUC that also is being deprecated. > > So what is the proper way to force default line endings? > > > -- > Now while composing this email I discovered String>>withUnixLineEndings. > So I have a solution... > testfile := 'README.md' asFileReference. > testfile ensureCreateFile writeStreamDo: [ :stream | > stream nextPutAll: 'aa > bb' withUnixLineEndings ]. > (testfile binaryReadStream contents at: 3) asCharacter "==> Character > lf " > > but that seems to imply that on Windows... > 'aa > bb' at: 3 "==> Character cr " > > and on Linux (someone please confirm)... > 'aa > bb' at: 3 "==> Character lf " > > and that is *very* curious. Strange that I never noticed it before and > obviously that hasn't hurt me, > but considering the Principal Of Least Surprise it leaves me feeling somewhat > violated :)
Re: [Pharo-dev] ZnMimePart
Hi Sven, On Mon, 15 Apr 2019 at 16:17, Sven Van Caekenberghe wrote: > > Hi Alistair, > > Sorry that it took a while to answer, but I did not forget. No problem, I'm a bit behind myself. :-) > > On 17 Mar 2019, at 07:55, Alistair Grant wrote: > > > > Hi Sven, > > > > I'm trying to parse maildir emails using ZnMimePart > > Cool. > > > and have a few questions: > > > > 1. The standard indicates that text lines should be terminated with > > CRLF, however in practice many maildir format emails (as saved by > > offlineimap and successfully handled by mutt) use LF. > > > > Are you open to modifying the parser to be a bit more forgiving, and > > allow CRLF, LF or CR? > > > > I could then completely deprecate MIMEDocument from the image and make > > MailMessage a bit more useful. > > Yes, being more forgiving about line end conventions would not hurt, it is > more or less standard practice in Pharo. Just make sure you don't break > anything else. I ended up writing a wrapper around the stream that converted random line endings to CRLF. After thinking about it a bit further I actually prefer this approach at the moment. There's a few places in the standard where it is quite specific about how to interpret the various options. Having the wrapper stream isolates the non-standard functionality and allows it to be easily removed. > > 2. ZnStringEntity and ZnByteArrayEntity both appear to answer their > > contents without decoding the data based on the > > Content-Transfer-Encoding, e.g. if I have: > > > > Date: Sat, 16 Mar 2019 12:00:21 +0100 > > MIME-Version: 1.0 > > Content-Type: image/jpeg; name="00585-capture.jpg" > > Content-Transfer-Encoding: base64 > > Content-Disposition: inline; filename="00585-capture.jpg" > > > > base64dataincludedhere... > > > > and send: > > > > aZmMimePart contents > > > > I'll get back the the result of evaluating: > > > > 'base64dataincludedhere...' asByteArray > > > > instead of the decoded data. > > > > Is this intended? I'd expect the decoded data (with charset decoding as > > well, in the case of text). > > I am not sure I fully understand: both ZnStringEntity>>#contents and > ZnByteArrayEntity>>#contents clearly return the internal string or bytes, so > the fully decoded data. > > A ZnMimePart considers its entity to be its contents. > > The handling of transfer headers is currently located outside these objects, > ZnEntityReader and ZnEntityWriter, as far as I remember. This feels correct. I'll have to get back to this. I'm side-tracked on other stuff at the moment, but thanks for your explanation. > > 3. What do you think of adding a few convenience test methods, e.g. > > isImage, isApplication, isText, etc.? > > That would be OK I guess. An alternative would be to add them to ZnMimeType, > then more clients could use them (as far as they are universal enough). Great. I'll get around to tidying up my modifications and submit them as a few PRs. P.S. I've successfully scanned about 35,000 emails. Thanks again, Alistair
Re: [Pharo-dev] New stable VM for Pharo8?
Hi Guille, On Tue, 2 Apr 2019 at 13:40, Guillermo Polito wrote: > > Hi all, Esteban, > > In the last sprint with Pablo and Pierre we have detected several > misbehaviours with files. > The issue was particular reproducible when trying to run iceberg tests: the > VM kind of ran out of slots for opening files. The strangest thing is that > the leaks seemed to happen when deleting directories, so we had a look at the > changes done to iterate directories, get file attributes and so on. > > While on the FileReference code everything seemed ok, we have observerd with > `lsof` that still several directories remained open even after deleting them. > > Latest VM fixes this issue but contains another one related to Metal > rendering, which prevents rendering in OSX versions < than High Sierra. > > Tracking the issue a bit, this seems to be a bug in the FileAttributes plugin > that was fixed by this PR by alistair > (https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc28298534dafbd0c26ea34fb). > > We have tested that particular commit > (a838346b1a67712cc28298534dafbd0c26ea34fb) and this one contains Alistair's > fixes but not yet the new rendering using Metal. We have been testing that VM > since yesterday and it seems stable, what do you think about marking it > stable for Pharo8? > > Regarding Pharo7, Pharo7's stable VM is the same as Pharo8's, so it contains > the same issue. However, since on the image side the code does not use the > problematic primitives, we do not think we need to change the VM for Pharo7 > (yet). However, there is seemingly a fix for directories containing blanks, > maybe Alistair can give us some input here? :) Cyril has already reported this issue in Pharo 8, so I agree that an updated VM for Pharo 8 would be nice. As you say, this doesn't affect Pharo 7 (or earlier). There is another, similar, issue that does affect Pharo 7 and earlier: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/368 which is resolved by: commit e9fee6facb61c1163e820673bd8734b59a831535 Author: AlistairGrant Date: Wed Feb 6 08:23:32 2019 +0100 FilePlugin: reopen the directory when jumping around In dir_Lookup, when jumping around, i.e. index ~= lastIndex+1, reopen the directory rather than rewinding. This is required as the open directory caches entries (at least with CIFS mounted file system), and if files are deleted between calls the wrong answer will be returned. Issue: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/368 This issue doesn't affect Pharo 8 since dir_Lookup() isn't used anymore. I'm only aware of this being reported once, and the issue has probably been there since 2010, or maybe even earlier. It is worthwhile being aware of it, but probably not enough to force a new VM for Pharo 7 immediately. Cheers, Alistair
Re: [Pharo-dev] Variables in auto-completion
On Thu, 28 Mar 2019 at 11:16, Cyril Ferlicot wrote: > > Hi, > > I remember that in old Pharo versions, the auto-completion added the > variables at the top of the completion list. Now they are at the > bottom under the classes. > > The original version worked better for me. The current version really > annoys me since most of the time I would prefer to have a variables > completed. Is there a setting somewhere to get the old behavior back? > If not, does someone knowing the implementation of the auto-completion > knows where I could put a metalink to get the old behavior back for > me? And me... :-) It's even more annoying because I can type the entire variable name and then continue typing only to get the variable replaced with some random class name. Cheers, Alistair
Re: [Pharo-dev] ZdcAbstractSocketStream>>peekFor:?
Hi Sven, On Sat, 16 Mar 2019 at 20:28, Sven Van Caekenberghe wrote: > > Here please, https://github.com/svenvc/zodiac Done. The changes were made in Pharo 8 and it's added lots of methodProperties.json files. I assume this is because you haven't had to make changes since Iceberg was updated. Let me know if it is a problem. Thanks, Alistair > > On 16 Mar 2019, at 20:23, Alistair Grant wrote: > > > > Hi Sven, > > > > On Sat, 16 Mar 2019 at 20:16, Sven Van Caekenberghe wrote: > >> > >> Since there is #peek there is no reason not to add #peekFor: as > >> > >> peekFor: object > >> "Answer false and do not move over the next element if it is not equal to > >> object, or if the receiver is at the end. > >> Answer true and move over the next element when it is equal to object." > >> > >> ^ self peek = object > >> ifTrue: [ > >>self next. > >>true ] > >> ifFalse: [ false ] > > > > Great, thanks. > > > > I'm happy to submit a PR, but vaguely remember that submitting it to > > pharo-project/pharo creates more work for you. Where should this be > > submitted (and in general for Zinc submissions)? > > > > Thanks again, > > Alistair > > > > > > > >> But note that the Zdc socket streams do not make a difference between > >> synchronous / asynchronous - IIRC I would say they block (they are also > >> always binary and flush when their buffer is full). > >> > >> Peeking in the context of a socket / network stream will block, just like > >> reading. > >> > >>> On 16 Mar 2019, at 19:44, Alistair Grant wrote: > >>> > >>> Hi Esteban, > >>> On Sat, 16 Mar 2019 at 19:37, Esteban Maringolo > >>> wrote: > >>>> > >>>> I don't know the answer but how could you peek for data that has yet not > >>>> come through the socket? In the buffer? Should it block? > >>> > >>> From memory: It depends on the mode of the stream: > >>> > >>> If synchronous: peeking will block until data is available. > >>> If asynchronous: if data is available, the next byte / character is > >>> returned. If no data is available, nil is returned. If nil is > >>> returned, you need to check if the socked is #atEnd to determine > >>> whether it is the end of the stream or just nothing available now. > >>> > >>> Cheers, > >>> Alistair > >>> > >>> > >>> > >>>> Regards. > >>>> > >>>> El sáb., 16 de mar. de 2019 12:23, Alistair Grant > >>>> escribió: > >>>>> > >>>>> Hi Sven, > >>>>> > >>>>> Unlike most streams that support #peek, ZdcAbstractSocketStream > >>>>> doesn't support #peekFor:. > >>>>> > >>>>> Is this intentional, or an oversight? > >>>>> > >>>>> Thanks, > >>>>> Alistair > >
[Pharo-dev] ZnMimePart
Hi Sven, I'm trying to parse maildir emails using ZnMimePart and have a few questions: 1. The standard indicates that text lines should be terminated with CRLF, however in practice many maildir format emails (as saved by offlineimap and successfully handled by mutt) use LF. Are you open to modifying the parser to be a bit more forgiving, and allow CRLF, LF or CR? I could then completely deprecate MIMEDocument from the image and make MailMessage a bit more useful. 2. ZnStringEntity and ZnByteArrayEntity both appear to answer their contents without decoding the data based on the Content-Transfer-Encoding, e.g. if I have: Date: Sat, 16 Mar 2019 12:00:21 +0100 MIME-Version: 1.0 Content-Type: image/jpeg; name="00585-capture.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="00585-capture.jpg" base64dataincludedhere... and send: aZmMimePart contents I'll get back the the result of evaluating: 'base64dataincludedhere...' asByteArray instead of the decoded data. Is this intended? I'd expect the decoded data (with charset decoding as well, in the case of text). 3. What do you think of adding a few convenience test methods, e.g. isImage, isApplication, isText, etc.? Thanks, Alistair
Re: [Pharo-dev] ZdcAbstractSocketStream>>peekFor:?
Hi Esteban, On Sat, 16 Mar 2019 at 19:37, Esteban Maringolo wrote: > > I don't know the answer but how could you peek for data that has yet not come > through the socket? In the buffer? Should it block? >From memory: It depends on the mode of the stream: If synchronous: peeking will block until data is available. If asynchronous: if data is available, the next byte / character is returned. If no data is available, nil is returned. If nil is returned, you need to check if the socked is #atEnd to determine whether it is the end of the stream or just nothing available now. Cheers, Alistair > Regards. > > El sáb., 16 de mar. de 2019 12:23, Alistair Grant > escribió: >> >> Hi Sven, >> >> Unlike most streams that support #peek, ZdcAbstractSocketStream >> doesn't support #peekFor:. >> >> Is this intentional, or an oversight? >> >> Thanks, >> Alistair >>
[Pharo-dev] ZdcAbstractSocketStream>>peekFor:?
Hi Sven, Unlike most streams that support #peek, ZdcAbstractSocketStream doesn't support #peekFor:. Is this intentional, or an oversight? Thanks, Alistair
Re: [Pharo-dev] MIMEDocument and MailMessage
Hi Marcus, On Wed, 13 Mar 2019 at 11:21, Marcus Denker wrote: > > Hi, > > The code is barely usable, I am sure it is not complete and wrong in many > places. Hopefully it will be a bit more usable and a little less wrong when I'm finished :-) I've been able to use it to parse and load mail headers (about 23,000 messages), so it isn't all bad. :-) Thanks, Alistair > > On 13 Mar 2019, at 11:09, Alistair Grant wrote: > > > > Hi Everyone, > > > > I'm playing with parsing and searching mail messages at the moment and > > am wondering about the interaction of MailMessage and MIMEDocument. > > > > A MailMessage contains a body which is a MIMEDocument, but if I request > > the parts of the body I get back multiple MailMessages, i.e. the parts > > of a MIMEDocument are a collection of MailMesssages. > > > > MIME documents are used outside of mail messages, e.g. HTTP, so the > > parts of a MIMEDocument should also be MIMEDocument's and not > > MailMessage's. This is also implied by the MIME description at > > wikipedia: https://en.wikipedia.org/wiki/MIME > > > > Some of the method comments seem to suggest that this was put together > > quickly, so it is possible that the intention was to do it properly at a > > later date (which never happened :-)). > > > > Am I missing something, or is it OK for me to modify MIMEDocument to > > return MIMEDocuments as the parts? > > > > > > Thanks, > > Alistair > > > >
[Pharo-dev] MIMEDocument and MailMessage
Hi Everyone, I'm playing with parsing and searching mail messages at the moment and am wondering about the interaction of MailMessage and MIMEDocument. A MailMessage contains a body which is a MIMEDocument, but if I request the parts of the body I get back multiple MailMessages, i.e. the parts of a MIMEDocument are a collection of MailMesssages. MIME documents are used outside of mail messages, e.g. HTTP, so the parts of a MIMEDocument should also be MIMEDocument's and not MailMessage's. This is also implied by the MIME description at wikipedia: https://en.wikipedia.org/wiki/MIME Some of the method comments seem to suggest that this was put together quickly, so it is possible that the intention was to do it properly at a later date (which never happened :-)). Am I missing something, or is it OK for me to modify MIMEDocument to return MIMEDocuments as the parts? Thanks, Alistair
Re: [Pharo-dev] #currentWorkingDirectoryPath is not correct on macOS when using drag and drop to open
Hi Max, On Fri, 8 Mar 2019 at 08:21, Max Leske wrote: > > Hi, > > OSPlatform>>currentWorkingDirectoryPath (used by Path>>workingDirectory, > used by Metacello to resolve local paths) always answers '/' for me when > I drag the image onto the VM to open. I'm sure that's a "feature" of > macOS but it's very annoying. > In addition, FileLocator imageDirectory answers the correct > workingDirectory because it uses a primitive instead of the FFI call to > getCwd(). > > Is this a known issue? Should I open a new one? This is known behaviour. #imageDirectory and #workingDirectory are distinct concepts. #imageDirectory, obviously, is the location where the image resides, while #workingDirectory is the current working directory for the process. It's unfortunate that MacOS sets cwd to "/" when starting applications through the GUI. It sounds like you are already aware of this, but just to be clear: if you start Pharo from a shell you should see #workingDirectory return the same value as `pwd` in the shell. I'm not a Mac user, so I don't know what other applications typically do, but maybe wrap the startup in a script that changes to something more sensible (in your case above it sounds like changing to the directory where the image is located). But modifying #workingDirectory to answer the image directory isn't a good idea as it breaks lots of other use cases. Cheers, Alistair
Re: [Pharo-dev] GT FileReference inspector menu items
Hi Doru, Thanks for your reply. On Sun, 3 Mar 2019 at 21:27, Tudor Girba wrote: > > Hi, > > > On Mar 3, 2019, at 3:45 PM, Alistair Grant wrote: > > > > Hi Doru, > > > > I've been adding menu items to the AbstractFileReference Items tab by > > modifying > > > > AbstractFileReference>>gtInspectorItemsIn: > > > > This obviously isn't a good way to add menu items as different > > packages will over-write each other and was wondering if an extensible > > framework had been included in the new GT toolkit (e.g. using pragmas > > to define the menu items)? (or am I missing something in Pharo 8)? > > You did not miss it. There is no option for this. > > > If not - consider this a feature request :-) > > We played with this in multiple ways and came to the conclusion that it is > too complicated and requires too much magic for the gain. > > There are two alternatives: > 1. extract specific views in a separate class and make that one be extensible > 2. offer a generic mechanism to disable unwanted views. This allows one to > provide an alternative view and disable the default one. OK. I'll (eventually) have a play with these ideas. Thanks again, Alistair > > P.S. The new String inspector as demoed in > > > > https://twitter.com/feenkcom/status/1102159122571710465 > > > > looks great! Being able to see the character easily is something I've > > wanted many times. > > I am happy you like it :) > > Cheers, > Doru > > > > > > Thanks! > > Alistair > > > > -- > www.feenk.com > > "There are no old things, there are only old ways of looking at them." > > > > > >
[Pharo-dev] GT FileReference inspector menu items
Hi Doru, I've been adding menu items to the AbstractFileReference Items tab by modifying AbstractFileReference>>gtInspectorItemsIn: This obviously isn't a good way to add menu items as different packages will over-write each other and was wondering if an extensible framework had been included in the new GT toolkit (e.g. using pragmas to define the menu items)? (or am I missing something in Pharo 8)? If not - consider this a feature request :-) P.S. The new String inspector as demoed in https://twitter.com/feenkcom/status/1102159122571710465 looks great! Being able to see the character easily is something I've wanted many times. Thanks! Alistair
Re: [Pharo-dev] Proposal to remove [Stream|Collection]>>#write:
On Fri, 22 Feb 2019 at 15:50, Esteban Maringolo wrote: > > El vie., 22 feb. 2019 a las 11:43, ducasse > () escribió: > > + 1 > > :) > > > But I’m an easy person when it is about cleaning. > > +1. That makes us two. +1 Cheers, Alistair
Re: [Pharo-dev] DeleteVisitor and symbolic links
Hi Sven & Torsten, On Wed, 13 Feb 2019 at 20:59, Torsten Bergmann wrote: > > Sven wrote: > > Thanks, Alistair, for taking care of all this stuff. > > +1 Thank you! Cheers, Alistair
[Pharo-dev] DeleteVisitor and symbolic links
Hi Everyone, I inadvertantly changed the behaviour of DeleteVisitor in Pharo 8. In Pharo 7 DeleteVisitor will follow all symbolic links when deleting a directory tree. This has two consequences: - A symbolic link that points to its containing directory will result in an infinite loop. - Files may be deleted that are NOT subdirectories of the root directory. The Pharo 8 behaviour of not following symbolic links is how the linux 'rm -r' command behaves, and how I think DeleteVisitor should behave. As Sean commented in http://forum.world.st/File-problems-in-Pharo-8-tp5095111p5095176.html following symbolic links can lead to unexpected behaviour, deleting files out of the tree, and thus is quite dangerous. But since it is a change in existing behaviour, I wanted to let everyone know in case there's something I haven't thought of. I'll submit a PR that updates the appropriate method and class comments in a few days. Cheers, Alistair
Re: [Pharo-dev] File problems in Pharo 8
Hi Cyril, On Tue, 12 Feb 2019 at 19:41, Cyril Ferlicot D. wrote: > > Le 12/02/2019 à 18:56, Alistair Grant a écrit : > > Hi Cyril, > > > > ... > > > > However any application that iterates over a large number of files could > > well be slower because the Guide / Visitor system retrieves entries. > > > > Thank you for the detailed explanation! > > > Do you know how many files are being deleted when the system feels > > slower? > > I was committing in Iceberg that is a Filetree repository. My change > impacted multiple package thus I would say it should be around 2500 > files and 500 folders. I wrote a class to measure the time taken by the Visitor / Guide - it's basically the same as the DeleteVisitor but just counts the number of files visited. Running this on a directory that contains 82331 files including 10169 directories. My 6 year old Dell XPS 13 (i7, SSD, 8G RAM) gives the following average times: Pharo 7: 3.7 seconds Pharo 8: 2.6 seconds I've attached the class below. > > It would be straightforward to modify the directory iteration primitives > > to only answer the file name instead of all attributes. I'll have a > > look and see how easy it would be to modify the Guide / Visitor objects > > to retrieve only file names instead of entire entries. > > > > So if possible it would make file copy/deletion even faster than before > IIUC? That would be really great! The Guide / Visitor framework uses file attributes to navigate the tree, so retrieving only file names wouldn't be useful. But I did notice that the entries weren't being initialised properly, so after fixing that bug the average run time for Pharo 8 drops: Pharo 8: 1.7 seconds I'll submit a PR with this fix. I also realised I inadvertently changed the behaviour of DeleteVisitor slightly. In Pharo 7 the Visitor will descend in to a symbolic link that points to a directory, in Pharo 8 it doesn't. This prevents the system from entering an infinite loop if the symbolic link points to the directory containing the link, but means that the set of files visited may be different. Pharo 7 may visit additional files that are currently skipped by Pharo 8, or it may visit some multiple times. I'll raise this as a separate discussion as I'm not sure that simply reverting to the old behaviour is a good idea. Cheers, Alistair AKG-Visitors.st Description: Binary data
Re: [Pharo-dev] File problems in Pharo 8
Hi Cyril, On Tue, 12 Feb 2019 at 11:57, Cyril Ferlicot wrote: > > On Tue, Feb 12, 2019 at 11:47 AM Alistair Grant wrote: > > > > Hi Cyril, > > > > In not at my PC at the moment, sorry. > > > > Can you try with vmLatest80? > > > > curl get.pharo.org/64/vmLatest80 | bash > > > > This looks like an issue I resolved recently. > > > > I can commit with this vm. Thank you. I'm glad you're able to commit now. :-) > I have the impression that the commit takes longer now but I don't > have any bench. (maybe it's just my imagination). A few comments on the performance: I haven't done a performance comparison for a while, and there have been a few changes in the plugin, so I'll keep it qualitative for now and try and run some more tests soon. FileReference>>exists should be significantly faster than before. It used to retrieve all the file attributes (an array of values, mostly integers and booleans). Now it just returns a boolean. Retrieving individual file attributes should also be faster. E.g. FileReference>>modificationTime also retrieved all file attributes and threw away everything except the desired attribute. Now it answers just the requested attribute. Retrieving a file entry, i.e. DiskDirectoryEntry, is probably a bit slower because more information is being retrieved than previously. FileReference>>exists gets called a lot. So do requests for individual file attributes. So my perception was that overall the system would probably be a bit faster than previously. However any application that iterates over a large number of files could well be slower because the Guide / Visitor system retrieves entries. Do you know how many files are being deleted when the system feels slower? It would be straightforward to modify the directory iteration primitives to only answer the file name instead of all attributes. I'll have a look and see how easy it would be to modify the Guide / Visitor objects to retrieve only file names instead of entire entries. Cheers, Alistair
Re: [Pharo-dev] File problems in Pharo 8
Hi Cyril, In not at my PC at the moment, sorry. Can you try with vmLatest80? curl get.pharo.org/64/vmLatest80 | bash This looks like an issue I resolved recently. Cheers, Alistair (on phone) On Tue., 12 Feb. 2019, 11:16 Cyril Ferlicot, wrote: > Hi, > > In Pharo 8 I have troubles because I get an error each time I try to > do an action calling a #deleteAll. > > I think the problem might have been introduced by the changes on Files > that were done to introduce FIleAttributes. > > I don't have much knowledge on this area and this is a little blocking > for me because when the problem triggers I cannot commit my changes > with Iceberg since it needs to delete folders. > > Bug report: https://github.com/pharo-project/pharo/issues/2495 > > -- > Cyril Ferlicot > https://ferlicot.fr > >
[Pharo-dev] Pillar branch names (was: ConfigurationOfGrease for Pharo8)
Hi Guille, On Mon, 4 Feb 2019 at 09:43, Guillermo Polito wrote: > > On Mon, Feb 4, 2019 at 9:28 AM Alistair Grant wrote: >> >> Hi Stef, >> On Mon, 4 Feb 2019 at 09:20, ducasse wrote: >> > >> >> The dev-7 branch loads fine in Pharo 8. >> >> > > But what do you mean by "now it is 70”? >> > >> > I thought that guillermo changed the dev-7 branch. > > Nope, I think that name is good, and then we manage releases using tags. We > have the following branches: What do you think of following the same naming convention as pharo-project/pharo, i.e. using branch names Pharo7.0 instead of dev-7? I think that would make it easier for newcomers. Cheers, Alistair
Re: [Pharo-dev] Roadmap for Pharo 8.0
Hi Esteban, On Thu, 7 Feb 2019 at 16:09, Esteban Lorenzano wrote: > > 2) Windows several missing/non working parts: > - file primitives are slow. This is because they rely in old APIs and we need > to put them in "state of the art". Is there somewhere I can read more about this? (I'm not disagreeing, just interested in what it means). Thanks, Alistair
Re: [Pharo-dev] ProcessBrowser does not auto-update itself by default? Should it?
On Mon, 4 Feb 2019 at 11:55, Sven Van Caekenberghe wrote: > > I believe the reason not to make auto updating the default, is because > #updateProcessList is a bit heavy (it calls a GC, does an #allSubInstances, > and it is a thread itself). Maybe that is no longer the case ? > > But adding a button to make auto updating easier to start would probably help. > > Maybe a button bar for more common actions (like terminate) ? > > > On 4 Feb 2019, at 11:47, Thomas Dupriez > > wrote: > > > > Hello, > > > > The Process Browser does not auto-updates itself by default to show new > > processes and hide processes that stopped. > > > > Is there a specific reason for that? The first time I opened it I kind of > > expected it would auto-update itself, and I think this may be a more > > "intuitive" behaviour that no auto-updates by default. What do you think? > > > > Getting auto-updates is "easy" (there is no button in the UI (something to > > improve?), but one can call the "toggleAutoUpdate" method to get this > > behaviour). My question is about it not being default. You can right click on a process and "Turn on auto-update", which is Ctrl-A (on linux). A button bar would be more friendly. Cheers, Alistair
Re: [Pharo-dev] ConfigurationOfGrease for Pharo8
Hi Stef, On Mon, 4 Feb 2019 at 09:20, ducasse wrote: > > Hi alistair > > >> HI alistair > >> > >> you should use the latest pillar. Was dev-7 and now it is 70 > >> because this is around six months that we removed the dependency to grease. > > > > I can see the dev-7 branch (which is what I'm using in Pharo 8). > > > And this is the one that broke? Strange. > Now we did not try Pillar in Pharo 80. > Could you try in Pharo70? No, the smalltalkhub version was "broken", but that's to be expected since it was out of date. The dev-7 branch loads fine in Pharo 8. > > But what do you mean by "now it is 70”? > > I thought that guillermo changed the dev-7 branch. > Ok I checked and this is a tag. 7.4.1 And that answers my question. Thanks, Alistair
Re: [Pharo-dev] ConfigurationOfGrease for Pharo8
Hi Stef, On Sun, 3 Feb 2019 at 21:56, ducasse wrote: > > HI alistair > > you should use the latest pillar. Was dev-7 and now it is 70 > because this is around six months that we removed the dependency to grease. I can see the dev-7 branch (which is what I'm using in Pharo 8). But what do you mean by "now it is 70"? Thanks, Alistair
Re: [Pharo-dev] ConfigurationOfGrease for Pharo8
Hi Cyril & Sven, I was loading an old version of Pillar, so that solves the Grease version info. Thanks again, Alistair On Sun, 3 Feb 2019 at 19:25, Alistair Grant wrote: > > Hi Cyril & Sven, > > Thanks for the pointer. I'll have to figure out why it is being > loaded from smalltalkhub - maybe Pillar? Anyway, I'll have a look. > > Thanks again, > Alistair > > On Sun, 3 Feb 2019 at 19:22, Cyril Ferlicot wrote: > > > > > > > > On Sun 3 Feb 2019 at 19:20, Alistair Grant wrote: > >> > >> Hi All, > >> > >> It looks like Grease is still hosted on smalltalkhub - if not, please > >> let me know where. > > > > > > Hi, > > > > Here: > > > > https://github.com/SeasideSt/Grease > > > > :) > > > >> > >> Are there any objections to me updating > >> ConfigurationOfGrease>>release1: to load on Pharo8? > >> > >> The updated method is (apologies for loss of formatting): > >> > >> release1: aSpec > >> > >> aSpec for: #'pharo3.x' version: #'release1.3'. > >> aSpec for: #'pharo4.x' version: #'release1.3'. > >> aSpec for: #'pharo5.x' version: #'release1.3'. > >> aSpec for: #'pharo6.x' version: #'release1.3'. > >> aSpec for: #'pharo7.x' version: #'release1.3'. > >> aSpec for: #'pharo8.x' version: #'release1.3'. > >> aSpec for: #'squeak5.x' version: #'release1.3'. > >> aSpec for: #'gs3.x' version: #'release1.3'. > >> aSpec for: #'pharo1.x' version: #'release1.2'. > >> aSpec for: #'pharo2.x' version: #'release1.2'. > >> aSpec for: #'squeak4.x' version: #'release1.2'. > >> aSpec for: #'gs2.x' version: #'release1.2' > >> > >> The change is the addition of the #'pharo8.x' line. > >> > >> Thanks, > >> Alistair > >> > > -- > > Cyril Ferlicot > > https://ferlicot.fr
Re: [Pharo-dev] ConfigurationOfGrease for Pharo8
Hi Cyril & Sven, Thanks for the pointer. I'll have to figure out why it is being loaded from smalltalkhub - maybe Pillar? Anyway, I'll have a look. Thanks again, Alistair On Sun, 3 Feb 2019 at 19:22, Cyril Ferlicot wrote: > > > > On Sun 3 Feb 2019 at 19:20, Alistair Grant wrote: >> >> Hi All, >> >> It looks like Grease is still hosted on smalltalkhub - if not, please >> let me know where. > > > Hi, > > Here: > > https://github.com/SeasideSt/Grease > > :) > >> >> Are there any objections to me updating >> ConfigurationOfGrease>>release1: to load on Pharo8? >> >> The updated method is (apologies for loss of formatting): >> >> release1: aSpec >> >> aSpec for: #'pharo3.x' version: #'release1.3'. >> aSpec for: #'pharo4.x' version: #'release1.3'. >> aSpec for: #'pharo5.x' version: #'release1.3'. >> aSpec for: #'pharo6.x' version: #'release1.3'. >> aSpec for: #'pharo7.x' version: #'release1.3'. >> aSpec for: #'pharo8.x' version: #'release1.3'. >> aSpec for: #'squeak5.x' version: #'release1.3'. >> aSpec for: #'gs3.x' version: #'release1.3'. >> aSpec for: #'pharo1.x' version: #'release1.2'. >> aSpec for: #'pharo2.x' version: #'release1.2'. >> aSpec for: #'squeak4.x' version: #'release1.2'. >> aSpec for: #'gs2.x' version: #'release1.2' >> >> The change is the addition of the #'pharo8.x' line. >> >> Thanks, >> Alistair >> > -- > Cyril Ferlicot > https://ferlicot.fr
[Pharo-dev] ConfigurationOfGrease for Pharo8
Hi All, It looks like Grease is still hosted on smalltalkhub - if not, please let me know where. Are there any objections to me updating ConfigurationOfGrease>>release1: to load on Pharo8? The updated method is (apologies for loss of formatting): release1: aSpec aSpec for: #'pharo3.x' version: #'release1.3'. aSpec for: #'pharo4.x' version: #'release1.3'. aSpec for: #'pharo5.x' version: #'release1.3'. aSpec for: #'pharo6.x' version: #'release1.3'. aSpec for: #'pharo7.x' version: #'release1.3'. aSpec for: #'pharo8.x' version: #'release1.3'. aSpec for: #'squeak5.x' version: #'release1.3'. aSpec for: #'gs3.x' version: #'release1.3'. aSpec for: #'pharo1.x' version: #'release1.2'. aSpec for: #'pharo2.x' version: #'release1.2'. aSpec for: #'squeak4.x' version: #'release1.2'. aSpec for: #'gs2.x' version: #'release1.2' The change is the addition of the #'pharo8.x' line. Thanks, Alistair
Re: [Pharo-dev] Spotter shortcut reset
Hi Ben, On Sat, 2 Feb 2019 at 11:01, Ben Coman wrote: > > On Sat, 2 Feb 2019 at 17:48, ducasse wrote: >> >> Ben >> >> How did you do it? >> I downloaded the latest version > > > By "latest version" do you mean direct download of Pharo 8.0 > > I don't have Pharo 8.0 listed in my Pharo Launcher. > I am getting network errors trying to download latest Pharo Launcher, > so I created a fresh Pharo 7.0.1 and Spotter works fine out of the box. > Then I used Iceberg to update to Pharo 8.0, this breaks Spotter. > Certainly not the recommended way, but its all I got at the moment to get > into Pharo 8.0 development. If you've got cygwin, you can use zeroconf: curl get.pharo.org/80+vm | bash or download directly: http://files.pharo.org/image/80/latest-32.zip http://files.pharo.org/vm/pharo-spur32/win/latest.zip (I think) HTH, Alistair
Re: [Pharo-dev] naming convention for pharo-vm/lib/pharo/* directory?
Hi Dale, On Fri, 25 Jan 2019 at 22:10, Dale Henrichs wrote: > > Thanks, Nicolas (and Sven), > > VM search path is what I am looking for (UFFI external modules) and I am > curious whether or not this path `pharo-vm/lib/pharo/5.0-201806281256` is > constant or variable for the various Pharo versions or does it vary based on > the vm version/build number ... pharo6.0 and pharo.1 appear to have the same > path ... haven't looked at Pharo7.0 ... and hopefully the path is the same > for mac and unix or does it vary ... I don't have a mac to readily test on:) > > The bash script that copies my unix/mac .so/.dylib files will be run > immediately after the image and vm have been downloaded so I won't be running > the image itself (unless I have to). Currently, the download, installation > and build of the pharo client for GemStone is built by a bash script... > > I'm going to assume for now that the gci libraries will be shoveled into the > pharo-vm/lib/5.0-* directory until someone gives me a more definitive > answer... pharo-vm/lib/5.0-* will probably work for any VM that is distributed through files.pharo.org, but may not be true for custom built VMs, e.g.: Installed via zero-conf: $ vm/pharo --version | grep plugin plugin path: /home/alistair/pharo7/pharo64.36/vm/pharo-vm/lib/pharo/5.0-201901051900 [default: /home/alistair/pharo7/pharo64.36/vm/pharo-vm/lib/pharo/5.0-201901051900/] vs built locally: $ vm.01/pharo --version | grep plugin plugin path: vm.01/lib/pharo/5.0-201901040101 [default: /home/alistair/pharo7/pharo64.36/vm.01/lib/pharo/5.0-201901040101/] Parsing the output of pharo --version is probably the best bet. HTH, Alistair
Re: [Pharo-dev] Build problems
Hi Stef, The "unbound variable" error has been fixed in https://github.com/pharo-project/pharo/pull/2368 (at least no one has complained in the last 8 hours :-)). Cheers, Alistair On Sun, 27 Jan 2019 at 20:35, ducasse wrote: > > Hi > > There are several problems with the build: > > First > > > [32] load : Refactoring2-Transformations-Tests-tonel.1 > > > [32] postload : baseline [BaselineOfIDE] >> postload:package: > > > [32] load : Deprecated70-tonel.1 > > > [32] postload : baseline [BaselineOfPharo] >> postload:package: > > > [32] + > /builds/workspace/uest_and_branch_Pipeline_PR-2362/32/bootstrap-cache/vmtarget/pharo > --headless Pharo7.0-PR-32bit-67f8280.image --no-default-preferences eval > --save 'FFIMethodRegistry resetAll. PharoSourcesCondenser condenseNewSources. > Smalltalk garbageCollect' > > > [32] pthread_setschedparam failed: Operation not permitted > > > [32] This VM uses a separate heartbeat thread to update its internal clock > > > [32] and handle events. For best operation, this thread should run at a > > > second > > > [32] + . > /builds/workspace/uest_and_branch_Pipeline_PR-2362/32/bootstrap/scripts/envversion.sh > > > [32] + set_version_variables > > > [32] > /builds/workspace/uest_and_branch_Pipeline_PR-2362/32/bootstrap/scripts/envversion.sh: > line 89: BOOTSTRAP_REPOSITORY: unbound variable > > > [Pipeline] [32] } > > > [Pipeline] [32] // dir > > > [Pipeline] [32] } > > > [Pipeline] [32] // stage > > > [Pipeline] [32] archiveArtifacts > > > [32] Archiving artifacts > > > [32] Recording fingerprints > > > [Pipeline] [32] cleanWs > > > [32] [WS-CLEANUP] Deleting project workspace... > > > [32] [WS-CLEANUP] Deferred wipeout is used... > > > [32] [WS-CLEANUP] done > > > [Pipeline] [32] } > >
Re: [Pharo-dev] [ANN] New stable VM version.
Hi Esteban, On Fri, 18 Jan 2019 at 14:49, Esteban Lorenzano wrote: > > Hi, > > Yes, I needed to promote a new stable version because last week’s was having > a bug (which is not fixed). > This one is based on the build: > > 201901172323-5a38b34 On Linux (Ubuntu 16.04) it's still the old VM: $ curl get.pharo.org/64/vm70 | bash % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 5320 100 53200 0 37021 0 --:--:-- --:--:-- --:--:-- 37202 Downloading the latest pharoVM: http://files.pharo.org/get-files/70/pharo64-linux-stable.zip pharo-vm/pharo Creating starter scripts pharo and pharo-ui $ ./pharo --version 5.0-201901051900 Sat Jan 5 19:12:50 UTC 2019 gcc 4.8 [Production Spur 64-bit VM] CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b64 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-f22c8934-2412-48ed-8180-7a42b62c7389 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /dev/shm/vm/pharo-vm/lib/pharo/5.0-201901051900 [default: /dev/shm/vm/pharo-vm/lib/pharo/5.0-201901051900/] Cheers, Alistair > Enjoy (and please report problems) > > Esteban
Re: [Pharo-dev] libssh2 1.7.0 & 1.8.0
--- Begin Message --- On Fri, 4 Jan 2019 at 10:36, Nicolas Cellier wrote: > > At the risk of being pedantic, if we were really serious, for mid term, it > would be good to not compile ssl, but just link. > > https://www.cvedetails.com/vulnerability-list/vendor_id-217/product_id-383/opdos-1/Openssl-Openssl.html We'll need to keep this on the ToDo list for this year: openssl 1.0.2 goes out of support this December 2019. The current version we're using, 1.0.2l, is also out of date, the current release being 1.0.2q. I'll probably have a go at building that version. Cheers, Alistair --- End Message ---
Re: [Pharo-dev] libssh2 1.7.0 & 1.8.0
Hi Guille, On Fri, 4 Jan 2019 at 09:54, Guillermo Polito wrote: > > Hi Alistair, > > On Fri, Jan 4, 2019 at 9:25 AM Alistair Grant wrote: >> >> Hi Esteban, >> >> The VM is currently being built with libssh2 1.7.0, but this doesn't >> build on ARM v6 (Raspberry Pi) due to changes in openssl. >> >> libssh2 1.8.0, which was released in October 2016, builds and appears >> to function correctly (the VM crashes when attempting to commit from >> within Iceberg, but I think this is an unrelated problem). > > > May I ask if you mean commit or push? I meant commit. I guess that it is doing a comparison of the image to the git repository to determine what has changed (to present the dialog saying which methods have changed). It's a call to free() that actually causes the problem. > Because commiting should not incure into any network activity and thus the > ssl is never used. Which is why I thought it is unrelated :-) > I don't know about the satus of libssl and libgit, but it is certain that > libgit uses libssl, so we have to be careful that the versions of libgit and > libssl are compatible. I cloned the pharo repository as a basic check that they are working together (plus the testing on Ubuntu). >> I've built and done some ad-hoc testing of libssh2 1.8.0 on linux 64 >> bit (Ubuntu 16.04) and haven't had any issues. >> >> What do you think of upgrading from libssh2 1.7.0 to 1.8.0? >> >> I don't know how close Pharo 7.0 is to release > > > Super close :) :-) Cheers, Alistair >> , but I expect this can >> wait until Pharo 8.0 if you prefer. > > > Or maybe for a 7.1? > We should be able to have easier and shorter release cycles in the future. > > Thanks Alistair ^^ > >> >> For convenience: https://www.libssh2.org/ >> >> Thanks, >> Alistair >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - http://www.cnrs.fr > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13
[Pharo-dev] libssh2 1.7.0 & 1.8.0
Hi Esteban, The VM is currently being built with libssh2 1.7.0, but this doesn't build on ARM v6 (Raspberry Pi) due to changes in openssl. libssh2 1.8.0, which was released in October 2016, builds and appears to function correctly (the VM crashes when attempting to commit from within Iceberg, but I think this is an unrelated problem). I've built and done some ad-hoc testing of libssh2 1.8.0 on linux 64 bit (Ubuntu 16.04) and haven't had any issues. What do you think of upgrading from libssh2 1.7.0 to 1.8.0? I don't know how close Pharo 7.0 is to release, but I expect this can wait until Pharo 8.0 if you prefer. For convenience: https://www.libssh2.org/ Thanks, Alistair
Re: [Pharo-dev] [Pharo-users] New book: Pharo with Style
--- Begin Message --- Hi Richard, On Tue, 1 Jan 2019 at 07:26, Richard O'Keefe wrote: > > ... > > To get an example, I did (String allSelectors atRandom), getting > #copyWithoutAll:. That has only one definition, in Collection: >copyWithoutAll: aCollection > "Answer a copy of the receiver that does not contain any elements > equal to those in aCollection." > > ^ self reject: [:each | aCollection includes: each] > > The comment simply paraphrases the rather simple code. I agree with pretty much everything you've written, but have a slightly different view here. Including what the method does, even when the code is fairly simple (OK, not getter / setter methods), is still useful. If the comment is absent, I have to look at the code, figure out what it does, and then either figure out if that's what it is supposed to do, or just assume that I'm correct. Having to figure out whether I've interpreted the code correctly just increases the cognitive load. If the comment includes what it is supposed to do, I have a context in which to read and evaluate the code, and it becomes much less effort. Cheers, Alistair --- End Message ---
Re: [Pharo-dev] [ANN] Pharo 8.0 development started
Hi Esteban, On Thu, 27 Dec 2018 at 15:52, Esteban Lorenzano wrote: > > Hi Alistair, > > I’m waiting to fix some issues in current VM build (new freetype lib, ensure > Athens will work on 64bit windows) and I was going to declare that “final vm > for Pharo7”. > Then this final VM for P7 will be the first for P8 :) Great, that will include the updates that I'm waiting for: updates to FileAttributesPlugin. I'll then be able to (finally) submit the patch for the image code. Thanks! Alistair > Esteban > > > On 27 Dec 2018, at 15:11, Alistair Grant wrote: > > > > Hi Esteban, > > > > Can I get in an early request for a new VM for Pharo 8? > > > > Since the normal process is to ensure the VM is at least 2 weeks old > > it doesn't require any action now, and of course it can wait until > > Pharo 7 is released. > > > > - Linux 64 bit: > > http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201812211409-1015842.zip > > - Mac 64 bit: > > http://files.pharo.org/vm/pharo-spur64/mac/pharo-mac-x86_64-201812211409-1015842.dmg > > - Win 32 bit: > > http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201812211809-e14d4d6.zip > > > > Thanks! > > > > Alistair > > > > On Thu, 27 Dec 2018 at 09:51, Esteban Lorenzano wrote: > >> > >> Hello all, > >> > >> We are preparing to release Pharo 7.0 (which will be in January, as soon > >> as we finish some last details). And in the meantime impatient people has > >> asked (and obtained) the aperture of Pharo 8.0 development! :) > >> > >> So you now can start making Pull Requests against Pharo8.0 branch :) > >> > >> Esteban > > > >
Re: [Pharo-dev] [ANN] Pharo 8.0 development started
Hi Esteban, Can I get in an early request for a new VM for Pharo 8? Since the normal process is to ensure the VM is at least 2 weeks old it doesn't require any action now, and of course it can wait until Pharo 7 is released. - Linux 64 bit: http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201812211409-1015842.zip - Mac 64 bit: http://files.pharo.org/vm/pharo-spur64/mac/pharo-mac-x86_64-201812211409-1015842.dmg - Win 32 bit: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201812211809-e14d4d6.zip Thanks! Alistair On Thu, 27 Dec 2018 at 09:51, Esteban Lorenzano wrote: > > Hello all, > > We are preparing to release Pharo 7.0 (which will be in January, as soon as > we finish some last details). And in the meantime impatient people has asked > (and obtained) the aperture of Pharo 8.0 development! :) > > So you now can start making Pull Requests against Pharo8.0 branch :) > > Esteban
Re: [Pharo-dev] Pharo 7 changelog proposal
Hi Pavel, You've mentioned the Zinc update and deprecating FileStream, but I think the adoption of Zinc streams as the default is probably worth it's own entry (that was Pharo 7, right?, maybe my memory is failing). Cheers, Alistair On Sun, 23 Dec 2018 at 12:29, Pavel Krivanek wrote: > > Hi, > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 merged > PRs, not counting standalone commits to Iceberg and Calypso). If something > more should be mentioned, please let me know. > > Revolutionary kernel changes > - bootstrap > - modular stateful traits > - traits flattening in kernel packages > - new sources file for every bootstrapped version, empty changes > - new class builder > - binary packages loading (Hermes) > > Infrastructure changes > - switch to GitHub > - Tonel code format > - update building infrastructure to Jenkins 2 > > Code management > - Calypso, the new system browser > - new navigation model > - faster UI > - tabs toolbar instead of single source code panel > - explicit commands instead of duplicated menu and shortcuts > - extendable by plugins > - suitable for the remote scenario > - "dynamic protocols", support multiple tags per method > - not required star convention for class extension > - support multiple tags per class > - visibility option for inherited methods > - methods inherited from traits are not shown by default > - variable view as the special mode for method group view. > - better keyboard navigation > - and many more > > Iceberg > - a new friendly user interface > - simplification of solving problems with repositories > - workflow simplification > - better GitHub, BitBucket, GitLab support > - improved code merging and comparisons > - new code serialization format (Tonel) > - repositories metadata > - documentation > - better error handling, tags support > - improved Iceberg-Metacello integration > - credentials store > > Cleanups > - remove Nautilus > - remove UpdateStream > - remove all Configurations > - remove ShoreLine-Report > - remove TxText > - remove PluggableTabBarMorph > - remove the old Compiler > - remove Watery theme > - remove Versionner > - remove Komitter > - remove LegacyWeakSubscription > - continue on deprecation of FileStream > - dead code cleanups > - code organization cleanups > - unify categorization of common methods > - cleanups of object inspection protocol > - start with Ring deprecation > - better structure of packages > - package comments > > Updates > - Zinc > - Epicea > - FFI > - Metacello > - Fuel > > New > - Calypso > - integrate WebBrowser > - integrate ReferenceFinder > - Hermes > - Refactoring 2 > - Commander > - ClassAnnotation > > Spec > - ComposableModel renamed to ComposablePresenter > - new calendar presenter > - Spec-Demo > - improve Spec linking to domain models > > Look & Feel > - use the white theme by default > - improve themes switching > - main menu bar > - new window management shortcuts > - better support of fallback bitmap fonts > - improved Inspector refreshing > - Spotter is looking for opened windows > - display scale factor > - FastTable improvements > > VM interface > - DoubleWord and DoubleByte arrays > - add EncoderForSistaV1 > - read-only literals support > - improvements and fixes for 64-bit support > - fixes for FullBlockClosure > - support of the new bytecode set > > Reflectivity > - breakpoints improvements > - test coverage using metalinks > - reflectivity and metalinks improvements > > Other > - startup running in a fresh process > - better pin messages > - NewValueHolder and Model API unification > - better working and image directories meaning separation > - SortFunctions composable > - better OSWindow support > - convert rules to the Renraku architecture > - class and method comments improvements > - extensible Playground (pageActionOrder:) > - optional password management for command line handlers > - system dependencies tests > - unify way to obtain package manifests
Re: [Pharo-dev] Catalog Entries
Hi Sven, On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe wrote: > > > > > On 19 Dec 2018, at 08:50, Alistair Grant wrote: > > > > Hi Sven, > > > > On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe wrote: > >> > >> I know about master and what it means, but that is not exactly what I want. > >> > >> When you release, that is a deliberate action: you put a stamp on the > >> current project timeline, declaring it as ready/stable enough for people > >> to depend on. > >> > >> The master branch can further evolve after a (latest) release. It is the > >> next release candidate. > >> > >> I would like to depend on whatever released version is the latest. See the > >> URLs in my previous email. > > > > I think your understanding of master is different from mine. master > > should never be the next release candidate, it is only ever the latest > > GA code. > > > > In that case, you can use master to mean "the latest GA version". > > > > If you want release candidates, they should be branches off > > development (or tags). > > > > If you want to support multiple versions, e.g. be able to release a > > 4.1 after 5.0 has been released, then each version should be branched > > off master (at the GA commit for that version). > > > > If you want to know where a named GA version is (and there won't be > > further updates), it is a tag on the master branch. > > I don't think/believe there is only one right way to use git, that is part of > its power. Agreed, and I can see how you read my reply that way, but I didn't mean to imply that "this is the one and only right way to do it". > In our eco system, with #stable and #bleedingEdge / #development versions of > ConfigurationsOf, it is my experience that very few people test before > something is released. Hence the only way to get feedback is to release. Only > if something has proven itself to be stable for some time can it receive a > release tag, IMHO. OK, so what I understand you're try to achieve is to have a "released" version and a "released and better tested" version. Doesn't this run the same risk of people just sticking to the "released and better tested" version, so the "released" version never gets the additional testing that's desired? > I also want to make things as simple as possible. :-) Cheers, Alistair
Re: [Pharo-dev] Catalog Entries
Hi Sven, On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe wrote: > > I know about master and what it means, but that is not exactly what I want. > > When you release, that is a deliberate action: you put a stamp on the current > project timeline, declaring it as ready/stable enough for people to depend on. > > The master branch can further evolve after a (latest) release. It is the next > release candidate. > > I would like to depend on whatever released version is the latest. See the > URLs in my previous email. I think your understanding of master is different from mine. master should never be the next release candidate, it is only ever the latest GA code. In that case, you can use master to mean "the latest GA version". If you want release candidates, they should be branches off development (or tags). If you want to support multiple versions, e.g. be able to release a 4.1 after 5.0 has been released, then each version should be branched off master (at the GA commit for that version). If you want to know where a named GA version is (and there won't be further updates), it is a tag on the master branch. Cheers, Alistair
Re: [Pharo-dev] Tonel>>sourceDir
Hi Ben, On Tue, 11 Dec 2018 at 12:32, Ben Coman wrote: > > Now the next question to the list, how would I determine which version of > Tonel (e.g. v1.0.9 or v1.0.11 or commit hash) > is loaded in an Image? - Open the Monticello Browser - Find MonticelloTonel-Core - Look at the repositories, in my (slightly older) Pharo 7 image it is: github://pharo-vcs/tonel:v1.0.9 Cheers, Alistair
Re: [Pharo-dev] Tonel>>sourceDir
Hi Ben, On Sun, 9 Dec 2018 at 16:06, Ben Coman wrote: > > > For Exercism we are using Tonel in Pharo 6.1. > We are getting an error "Instance of TonelWriter did not understand > #sourceDir:" > but the same code works fine on Pharo 7. > > The 6.1 image had been updated to latest Iceberg per > https://github.com/pharo-vcs/iceberg#for-pharo-61, so I used ICeberg to > updated to latest "master" of pharo-vcs/tonel but no avail. > > In Pharo 7 I see TonelWriter>>sourceDir in protocol "accessing" > but if I search for "sourceDir" in the pharo-vcs/tonel repo it doesn't find > it... > https://github.com/pharo-vcs/tonel/search?q=sourcedir_q=sourcedir > > I'm having trouble understanding where the #sourceDir method comes from in > Pharo 7. > Which repo/branch can I load that from into another system? It seems like v1.0.9 has it and master doesn't, see: https://github.com/pharo-vcs/tonel/tree/v1.0.9/MonticelloTonel-Core.package/TonelWriter.class/instance (based on just hunting around my Pharo 7 image, I don't really understand the code :-)) HTH, Alistair
[Pharo-dev] Which version of libfreetype.dll?
Hi Esteban, If I zeroconf Pharo 7 on Windows (in cygwin): $ curl get.pharo.org/70+vmLatest | bash And then move to a dos box: C:\cygwin\tmp\p7>pharo-vm\PharoConsole.exe --headless Pharo.image eval "FT2Library current libraryVersion" 2.6.5 Is this what you expect? Thanks, Alistair
Re: [Pharo-dev] [Pharo-users] [ANN] Pharo v7.0.0-rc1 released!
Hi Vitor, On Wed, 14 Nov 2018 at 14:37, Vitor Medina Cruz wrote: > > Got instant red crossed welcome window on windows 7 64bits with the Pharo 7 > 64 bits: "Error: Instances of SourceFileArray are not indexable". I will try > on a windows 10 version later. Which VM are you using? (pharoconsole --version) I've seen this just once on Ubuntu 16.04 (64 bit), but wasn't able to reproduce it, and think it was a more recent VM than the current stable version. Thanks, Alistair
Re: [Pharo-dev] Pharo 7 RC - Changing to larger font breaks scrolling in code browsers
Hi Sven, On Mon, 12 Nov 2018 at 17:08, Sven Van Caekenberghe wrote: > > Hi, > > Here is an annoying usability bug that I am experiencing and that sometimes > drives me nuts. It has been there a while. > > Take a stock Pharo 7 RC image and don't change any setting. Browse the method > #testAsDateAndTime as implemented by DateAndTimeTest. This is a (too) long > (test) method. Any long method will do. > > You can scroll it fine in both the implementors and well as in the full > browser. > > Now switch to 'Medium' sized 'predefined style' Standard Fonts using the > Settings Browser. > > It is now close to impossible to scroll in the implementors or the full > browser: not using the scroll bar arrows, not dragging the scroll bar, not > clicking above/below the scroll bar, not using the scroll gesture (track pad, > mouse pad, wheel), not using cursor keys inside the editor. Scrolling seems > to happen automatically and goes on until the top or bottom. > > Can anyone replicate this ? On Ubuntu 16.04 with recent images I can reproduce the behaviour, with the following additional observations: - It doesn't seem to matter whether true type fonts are enabled or not. - After increasing the font size to medium and opening the browser: -- The (vertical) scroll bar isn't visible, it is possible to scroll using the mouse wheel or cursor keys. -- Increasing the width of the browser so the scroll bar is visible, but not clicking on the scroll bar, scrolling using the mouse wheel or cursor keys still works. -- Once the scroll bar has been clicked on it fails as you describe. HTH, Alistair.
Re: [Pharo-dev] How do I create a binary stream
Hi Stef, On Sun, 11 Nov 2018 at 10:04, Stephane Ducasse wrote: > > Hi > > I'm checking some of the mooc code in Pharo 70. > > The Pharo 50/60 version is > > PNGReadWriter createAFormFrom: 'Sprites.png' asFileReference > binaryReadStream upToEnd > > I came up with > > PNGReadWriter formFromStream: (File named: 'Sprites.png') readStream > > And we can also have > > PNGReadWriter formFromStream: 'Sprites.png' asFileReference binaryReadStream > > I will add this in the comment of the formFromStream: method. FileReference is the normal public interface to the file system, while File is a low level API that is only used in limited circumstances, e.g. bootstrapping when FileSystem isn't yet available. Most users shouldn't have to worry about File, so I'd leave it out as an example. Cheers, Alistair
Re: [Pharo-dev] PharoLauncher : Image version determination error
Hi Christophe, On Fri, 9 Nov 2018 at 15:15, Christophe Demarey wrote: > > For now, to work around the problem, I will add a windows to easily update > the VMs from the launcher UI. It should be possible to check if there is a new VM by just requesting the headers for the download URL. You could then add a "Check for new VM" button / menu item, and maybe even have a setting to do it each time the launcher is started. Cheers, Alistair
Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha
Hi Marcus, On Wed, 7 Nov 2018 at 14:27, Marcus Denker wrote: > > > > > On 7 Nov 2018, at 13:56, Alistair Grant wrote: > > ... > > > Good point. How to get a list of all the methods that have MetaLinks? > > The following seems to work, but probably isn't the most efficient: > > > > Object allSubclasses flatCollect: [ :each | each methods select: [ > > :method | method ast links isNotNil ] ] > > > > you can ask the method directly > > Object allSubclasses flatCollect: [ :each | each methods select: [ > :method | method hasLinks ] ] > > this is much faster as it returns immediately nil for methods without links > (without AST reification). Thanks! Cheers, Alistair
Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha
Hi Sven, On Wed, 7 Nov 2018 at 10:37, Sven Van Caekenberghe wrote: > > > > > On 7 Nov 2018, at 10:27, Alistair Grant wrote: > > > > Hi Alex, > > > > > > On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel wrote: > >> > >> Hello, > >> > >> When saving one of the latest pharo70 image I got an infinite recursion > >> loop due to message not understood. Force closing it probably lead to > >> image corruption and it became un-openable anymore. Any idea what is going > >> on? It does not look like a unique case because there are a few pharo70 > >> images that already died in front of me... > > > > This looks like your image changes the definition of > > Number>>raisedToInteger: somewhere along the line. In the standard > > image it doesn't call #run:with:in:. > > I don't think that definition got overwritten, check the implementers of > #run:with:in: is seems to have to do with meta links or proxies or something > like that ... Good point. How to get a list of all the methods that have MetaLinks? The following seems to work, but probably isn't the most efficient: Object allSubclasses flatCollect: [ :each | each methods select: [ :method | method ast links isNotNil ] ] Cheers, Alistair
Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha
Hi Alex, On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel wrote: > > Hello, > > When saving one of the latest pharo70 image I got an infinite recursion loop > due to message not understood. Force closing it probably lead to image > corruption and it became un-openable anymore. Any idea what is going on? It > does not look like a unique case because there are a few pharo70 images that > already died in front of me... This looks like your image changes the definition of Number>>raisedToInteger: somewhere along the line. In the standard image it doesn't call #run:with:in:. HTH, Alistair
Re: [Pharo-dev] Unable to repair repository
Hi Guille, On Tue, 6 Nov 2018 at 10:43, Guillermo Polito wrote: > > Hi Alistair, > > On Tue, Nov 6, 2018 at 9:39 AM Alistair Grant wrote: >> >> Hi Everyone, >> >> In the latest Pharo (88c6b8d), attempting to repair the pharo >> repository, i.e. clone it, first a warning is raised: >> >> "There is no associated repository configured." >> >> and then a DNU: #pathString was sent to nil. >> >> The DNU is because IceTipCopyCommitishCommand>>canBeExecutedInContext: >> now sends #commitId instead of #shortCommitId. >> IceTipRepositoryModel>>shortCommitId has an exception handler, while >> #commitId doesn't. >> >> Can someone explain why the warning was added? It is a bit annoying >> to have to click through dialogs telling me that the repository I'm >> trying to create needs to be created. > > > I've seen that yesterday evening, and I've fixed it here > https://github.com/pharo-vcs/iceberg/issues/1068. > I've put links on the original issues that caused the regression, and the > workaround meanwhile we prepare a new version. > > A fix will be pushed in a 1.3.2 version in the following hours ^^. Cool, thanks! (I had already added the exception handler to #commitId as a partial workaround). >> Using the generic Error exception handler has the risk of hiding other >> problems. Wouldn't it be better to create a IceRepositoryMissing >> error, or similar? > > > The support for missing repositories should be indeed revisited a bit and > enhanced. > Particularly, we have other issues related to this that we have not worked on > yet like this one: > > https://github.com/pharo-vcs/iceberg/issues/949 > > This issue is pretty important, but no time to work on it yet, so if someone > wants to propose a solution, we take it :)... I'm trying to review Pavel's PR #1953 [1], but may take a look afterwards. Thanks again, Alistair [1] https://github.com/pharo-project/pharo/pull/1953
[Pharo-dev] Unable to repair repository
Hi Everyone, In the latest Pharo (88c6b8d), attempting to repair the pharo repository, i.e. clone it, first a warning is raised: "There is no associated repository configured." and then a DNU: #pathString was sent to nil. The DNU is because IceTipCopyCommitishCommand>>canBeExecutedInContext: now sends #commitId instead of #shortCommitId. IceTipRepositoryModel>>shortCommitId has an exception handler, while #commitId doesn't. Can someone explain why the warning was added? It is a bit annoying to have to click through dialogs telling me that the repository I'm trying to create needs to be created. Using the generic Error exception handler has the risk of hiding other problems. Wouldn't it be better to create a IceRepositoryMissing error, or similar? Thanks, Alistair
Re: [Pharo-dev] Source/changes file suffixes constants
Hi Sven, On Wed, 31 Oct 2018 at 16:44, Sven Van Caekenberghe wrote: > > Hi, > > Current FileStream holds (in the protocol 'file reader services') some > constants regarding source/changes file suffixes. > > Where should we move these to (as FileStream is deprecated) ? > > There is a class SourceFile, there is PharoFilesOpener, neither seems to fit > that well. > > Suggestions ? Can you clarify why you think SourcFile is not a good candidate? #changesFileSuffixes, #isChangesFileSuffix:, #isSourceFileSuffix:, #sourceFileSuffixes all relate to specifying source files, so could possibly go to SourceFile. #fileIn: should be deprecated. FileReference>>fileIn provides the same functionality. #removeLineFeeds: seems to be unused. Deprecate as well? Cheers, Alistair
Re: [Pharo-dev] ZipArchive and symbolic links
Hi Cyril, I haven't looked at ZipArchive at all, but I would be very surprised if it did work with symbolic links. FilePlugin has no way to create a symbolic link, and the test for a symbolic link (#isSymlink) is broken (I've got a fix, but it's taking much longer to get it finished than I ever thought). Cheers, Alistair On Tue, 2 Oct 2018 at 13:42, Cyril Ferlicot wrote: > > Hi! > > I just found that ZipArchive does not honor symbolic links (at least > in Pharo 7). > > I would like to know if this is a known bug? I found out because I was > using Pharo to unzip some Pharo vms and it broke all the dynamic > libraries :( > > -- > Cyril Ferlicot > https://ferlicot.fr >
Re: [Pharo-dev] [Pharo-users] [ANN] Migrated Artefact to GitHub
Hi Guille, I wasn't aware this existed - thanks for letting us know! Cheers, Alistair On Thu, 27 Sep 2018 at 15:41, Norbert Hartl wrote: > > Super! Thanks > > Norbert > > Am 27.09.2018 um 11:26 schrieb Guillermo Polito : > > Hi all, > > I've moved the Artefact library to GitHub > (https://github.com/pharo-contributions/Artefact). > > I've also made some changes to it in the way and made a 1.7.0 version with: > - support for Pharo7 streams > - a baseline > > So, people using Artifact, you can contribute through pull requests ^^, > Guille > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - http://www.cnrs.fr > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13
Re: [Pharo-dev] Files-Core and Zinc-Character-Encoding-Core package load sequence
Hi Sven & Guille, On Tue, 25 Sep 2018 at 10:49, Guillermo Polito wrote: > > > > On Mon, Sep 24, 2018 at 11:23 PM Sven Van Caekenberghe wrote: >> >> >> >> > On 24 Sep 2018, at 21:55, Alistair Grant wrote: >> > >> > Hi Guille, Sven, Esteban and Everyone, >> > >> > Can someone (dis)confirm that the Zinc-Character-Encoding-Core package is >> > considered part of the pharo "core" image? >> >> Yes, for me anyway, it is (or should be) part of core. > > > Yes, they are part of the Core image. Simply because an image without any I/O > is an image you cannot interact with, so it's kind of useless :) > And an image doing I/O without managing encoding is pretty useless too... Thanks for the confirmation. I suspected this was the case, but didn't want to be wrong later on. > Also, keep in mind that we try to maintain Zn packages in sync with Sven's > repository, and we try to keep them loadable/compatible with other pharo > versions. > Usually Zn encoders should be stable enough in terms of API and features, but > in case you need to extend them in some way we should keep Sven in the loop > so we can sync both repositories ^^. Sure, at the moment I can't envisage any required changes. Thanks again, Alistair
[Pharo-dev] Files-Core and Zinc-Character-Encoding-Core package load sequence
Hi Guille, Sven, Esteban and Everyone, Can someone (dis)confirm that the Zinc-Character-Encoding-Core package is considered part of the pharo "core" image? The reason I ask is that I'd like to know whether the File class (which is part of the Files-Core package) can count on ZnUTF8Encoder (which is part of the Zinc-Character-Encoding-Core package) being present in the image. If File can count on ZnUTF8Encoder being present then for FileAttributes I will make UTF8 encoding / decoding available from File, and thus UTF8 file names will be supported. If it can't count on ZnUTF8Encoder being present then File will only be able to handle ascii file names (unless the names are somehow already UTF8 encoded) and support for UTF8 file names will effectively be restricted to FileSystem. Thanks, Alistair
Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage
Hi Petr, On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev wrote: > > Hello, I want to propose some small fixes to Pharo, it took me hours just to > run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)... > > Now I am stuck with this Iceberg error: > https://app.box.com/file/321243070589 I was presented with a login box when I tried to view this. > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest > CentOS7) - is Iceberg OK on 64bits? Yes, I use it all the time (on Ubuntu 16.04 64 bit). Cheers, Alistair
Re: [Pharo-dev] Platform file encoding for FFI
On Wed, 19 Sep 2018 at 10:26, Guillermo Polito wrote: > > On Tue, Sep 18, 2018 at 4:40 PM Alistair Grant wrote: >> >> I realise of course that this could all be done in FFI, and I agree with >> all Estaban's arguments in favour of FFI, my main motivation was that >> the code is already in the VM, and to avoid code duplication with the >> obvious benefit that if a bug is fixed it will apply everywhere. > > > Yeh. At the end it's a matter of debugging cycles. > Imagine making the "compile-restart" steps that you're facing while changing > the plugin almost negligible in the "change-compile-restart-test" loop :). This is true if the code only resides in the image, but in this case the code won't be going away from the VM any time soon. Anyway, for whoever does implement the code for FFI the option is always there. Thanks to everyone for their replies! Cheers, Alistair
Re: [Pharo-dev] Platform file encoding for FFI
Hi Guille, Esteban and Henry, Thanks for your replies. On Tue, Sep 18, 2018 at 10:09:02AM +0200, Guillermo Polito wrote: > > > On Mon, Sep 17, 2018 at 6:52 PM Alistair Grant wrote: > > Hi Esteban, Guille and Everyone, > > I haven't looked at using FFI much, however it is easy to imagine that > different file encoding rules on different platforms will make writing > FFI calls more difficult, > > > Well not really (from my point of view :)) > From the point of view of the FFI call an encoded string is just a bunch of > bytes. FFI does not do any interpretation of them. Right, but getting the appropriately encoded bunch of bytes is the issue. :-) > i.e. some of the different formats are: > > - OSX uses Mac specific decomposed UTF8 encoding > - Windows uses Wide Strings (16 bit Unicode characters) > - Linux allows pretty much anything, but precomposed UTF8 is common > > > > At the image side, we could have an strategy that, depending on the OS, could > encode in one encoding or another, or even not encode at all. > > > Believe it or not, I'm still working on getting the > FileAttributesPlugin working (file name encoding on Windows being the > latest issue - the tests in Pharo need to be extended). > > > I believe you, don't worry ^^. > > > Would it be useful for future FFI work to have primitives available > which convert file names to and from the various platform specific > formats? (Linux is basically a no-op, and Windows could be written > in-image, but OSX requires the platform routines to be called). > > > Maybe... Are the OSX routines exposed as C functions (that we can call through > FFI) or they are objective-C methods/functions (that are more complicated to > map)? The OSX routines are exposed as C functions (and available as Objective-C methods), see convertChars() in platforms/unix/vm/sqUnixCharConv.c. On Tue, Sep 18, 2018 at 11:21:41AM +0200, Esteban Lorenzano wrote: > > self > >ffiCall: #(bool saveContentsToFile(String fileName, String contents)) > >options: #(+stringEncodings( fileName return , platformAPI contents) > > This is cool. > What I do not like is to rely on primitives to do that encoding. > This should be in image??? using FFI if needed (this is all because we > want to rely less and less on plugins :P) I realise of course that this could all be done in FFI, and I agree with all Estaban's arguments in favour of FFI, my main motivation was that the code is already in the VM, and to avoid code duplication with the obvious benefit that if a bug is fixed it will apply everywhere. On Tue, Sep 18, 2018 at 11:23:56AM +0200, Esteban Lorenzano wrote: > > > On 18 Sep 2018, at 11:04, Guillermo Polito > wrote: > > > > On Tue, Sep 18, 2018 at 10:43 AM Henrik Sperre Johansen < > henrik.s.johan...@veloxit.no> wrote: > > It *would* be pretty handy for adding some auto-conversion into the > marshaller based on parameter encoding options though... (other than > filename, could be done in smalltalk using exisiting encoders) > > self > ffiCall: #(bool saveContentsToFile(String fileName, String > contents)) > options: #(+stringEncodings( fileName return , platformAPI > contents) > > > Well, I like this idea. > > > (And yes, I've probably badly mangled the options syntax) > > Is much less verbose than having to manually convert Strings to the > proper > platform Unicode encodings before calling. > Depends a bit on whether the primitive argument is > Byte/Widestrings(latin1/utf32), or if it accepts only utf8 bytes and > one has > to convert first anyways. > > It's not like this isn't a pain point, there are plenty of currently > used > API's that are broken if you try to use non-ascii. > > > Yes, but I think this may be because in general people tend to not know > how > encodings work... (even myself I don't feel I know enough :)) > But this makes me think that we should make encoding explicit? > > > Yup, explicit please. Nothing hide behind the carpet :) > > > > Maybe we should force people to specify an encoding if they specify a > callout using a string. > > And then, either they specify it at the level of the callout, or at the > level of the library (like setting a default encoding for all strings). > > > > You can have some global FFI settings (I was thinking on adding some global > options settings for FFI in general
[Pharo-dev] Platform file encoding for FFI
Hi Esteban, Guille and Everyone, I haven't looked at using FFI much, however it is easy to imagine that different file encoding rules on different platforms will make writing FFI calls more difficult, i.e. some of the different formats are: - OSX uses Mac specific decomposed UTF8 encoding - Windows uses Wide Strings (16 bit Unicode characters) - Linux allows pretty much anything, but precomposed UTF8 is common Believe it or not, I'm still working on getting the FileAttributesPlugin working (file name encoding on Windows being the latest issue - the tests in Pharo need to be extended). Would it be useful for future FFI work to have primitives available which convert file names to and from the various platform specific formats? (Linux is basically a no-op, and Windows could be written in-image, but OSX requires the platform routines to be called). Cheers, Alistair
Re: [Pharo-dev] Release test for unused temps and other
On Thu, 6 Sep 2018 at 23:06, Cyril Ferlicot D. wrote: > > > Maybe we could have a package with release tests that are not executed > by the CI but that are executed at the moment of the feature freeze and > some time before the Pharo release to ensure the quality of the code > base for tests that are too long? The drawback of this approach is that it relies on the original author going back and submitting a fix in a timely manner (quite possibly after they've moved on to other things). If the tests could be run on a specified set of classes / methods, perhaps we could run them as part of Iceberg, i.e. when going to commit code, these tests are run on the classes in the commit and a warning opened prompting the user to fix them before actually committing. Cheers, Alistair
Re: [Pharo-dev] Promote new Pharo 7 VM (d952580)
Hi Esteban, I've found a UTF8 coding issue on Windows in the plugin. I'll have to resolve that, so no hurry on the release now (I'll also update FileSystemTest>>testFileNames so it is covered). Sorry for the noise. Thanks, Alistair On Sat, 1 Sep 2018 at 11:13, Esteban Lorenzano wrote: > > Hi, > > I’m currently in holidays, I will start the process next monday :) > > Esteban > > > > On 30 Aug 2018, at 10:38, Alistair Grant wrote: > > > > Hi Esteban and Everyone, > > > > I would like to request we start the process for promoting a new Pharo 7 > > VM. d952580 (vmLatest as I write this) has two changes that I'm > > looking forward to: > > > > - Fix path encoding / decoding on OSX > > Hopefully this will finally allow me to submit the File Attributes > > changes (fogbugz 18279[1] & 21368[2]). > > - Add primitiveChangeMode(), primitiveChangeOwner() and > > primitiveSymlinkChangeOwner() > > This will allow Pharo to set file owner & group IDs and posix > > permissions on Unix platforms (Linux & OSX). > > > > > > Other changes include: > > > > - stdio is flagged correctly on Windows > > - Windows 64 bit work > > - fflush added to sqFileTruncate() > > - Eliot's work on Cog > > - Everything else I've missed :-) (sorry to those authors) > > > > > > Running the automated test suite on Linux 32 bit, Linux 64 bit and > > Windows 32 bit produces basically the same set of failures with the > > current stable VM and the proposed VM. > > > > [1] > > https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Linux > > [2] https://pharo.fogbugz.com/f/cases/21368/Integrate-FileAttributesPlugin > > > > > > Thanks, > > Alistair > > > >
