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

Re: [Pharo-dev] Smalltalk to Smalltalk interface

by Dale Henrichs

On 5/30/19 11:09 AM, ducasse wrote: > I know that people some people ported STON to VW and used it to be able to build nice new > systems in Pharo while talking to their old software in VW. > So this is a nice way to migrate :) STON has also been ported to GemStone and likely to be ported to VA as well ... > > Stef > >> On 30 May 2019, at 12:31, askoh <askoh(a)askoh.com> wrote: >> >> Hi: >> >> While working on VisualWorks-Python interface, it occurred to me why not >> have VisualWorks-Pharo interface too. >> Has something like that been attempted? One Smalltalk dialect to Another >> Smalltalk dialect interface? >> What would be a good way to interface them? Master-Slave? Peer to Peer? >> >> Thanks, >> Aik-Siong Koh >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > >

May 30, 2019

Re: [Pharo-dev] Smalltalk to Smalltalk interface

by ducasse

I know that people some people ported STON to VW and used it to be able to build nice new systems in Pharo while talking to their old software in VW. So this is a nice way to migrate :) Stef > On 30 May 2019, at 12:31, askoh <askoh(a)askoh.com> wrote: > > Hi: > > While working on VisualWorks-Python interface, it occurred to me why not > have VisualWorks-Pharo interface too. > Has something like that been attempted? One Smalltalk dialect to Another > Smalltalk dialect interface? > What would be a good way to interface them? Master-Slave? Peer to Peer? > > Thanks, > Aik-Siong Koh > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

May 30, 2019

Smalltalk to Smalltalk interface

by askoh

Hi: While working on VisualWorks-Python interface, it occurred to me why not have VisualWorks-Pharo interface too. Has something like that been attempted? One Smalltalk dialect to Another Smalltalk dialect interface? What would be a good way to interface them? Master-Slave? Peer to Peer? Thanks, Aik-Siong Koh -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 30, 2019

Re: [Pharo-dev] Versioning with Iceberg

by Ben Coman

On Wed, 29 May 2019 at 23:08, Shaping <shaping(a)uurda.org> wrote: > Iâm finding 7.0.3 to be more stable. > > > > How do I load a specific baseline/version with Iceberg? Iâm getting 8.0 > by default from the cloned local repo, and I prefer not to merge 7.0.3 with > 8.0. There are many differences. I want to commit my image changes > locally for now on a 7.0.3. > > > Is this what you need... ? https://github.com/pharo-vcs/iceberg/issues/1246 cheers -ben

May 30, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Ben Coman

On Thu, 30 May 2019 at 18:56, Shaping <shaping(a)uurda.org> wrote: > > > I prefer to use one tool for versioning. Is that possible now in any > version of Pharo? Can I use only Iceberg for all fetches and all > commits? Or must I sometimes use evaluables like: > > > > Metacello new > > baseline: 'Exercism'; > > repository: 'github://exercism/pharo-smalltalk/releases/latest'; > > onConflict: [ :ex | ex allow ]; > > load. > Metacello operates at a higher level than Iceberg. Iceberg (like Monticello) versions individual packages. Metacello defines the version dependencies between packages, including different git repos and Monticello repos. The Metacello definition is versioned like any other code, using either Iceberg or Monticello. I'm not completely sure, but I think Metacello uses Iceberg to load from github repos, so what that last code snippet does is... Metacello loads the given baseline from github using Iceberg and parses it, then loads all the dependent baselines from their respective repos using Iceberg or Monticello per the format they are stored in, then loads all the specified code versions using Iceberg or Monticello as appropriate. Also once you've loaded an Iceberg repo containing a Metacello baseline, you can invoke that baseline from within Iceberg. [image: image.png] Essentially Iceberg replaces Monticello for git repos, but there is a wealth of historical packages in Monticello format, so its not disappearing either. HTH, cheers -ben

May 30, 2019

Re: [Pharo-dev] Calypso idea - inherited tests

by ducasse

I will try to save them when I get them. > On 30 May 2019, at 08:09, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi guys. > > Would be nice to see the error stack. > Which variable is nil in that case? > > I really do not see such errors. Is it pharo 7 or 8? > > > ÑÑ, 30 Ð¼Ð°Ñ 2019 Ð³., 11:17 ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>>: > > >> On 29 May 2019, at 23:58, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >> >> >> >> On Thu, 30 May 2019 at 06:26, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> Hi Ben. >> >> There are already two features that support inherited tests: >> - run all tests using class icon: there will be extra red method group "broken tests" which will show failed inherited tests. >> - toggle inheritance visibility with checkbox in third panel: you will see inherited tests and standard method icon will run them. >> >> Ahh, excellent... the second is exactly what I wanted. >> >> Although using TestDelaySemaphoreSchedulerMicrosecondTicker as an example, >> clicking on a test gives me an error "#selected was sent to nil" in "ClyBrowserToolMorph>>isTabSelected" >> Do you get the same? > > Yes this happens to me often. > I think that calypso forks too many processes. >> >> cheers -ben >> >

May 30, 2019

Re: [Pharo-dev] Pharo Launcher failing in Windows 10

by Cyril Ferlicot D.

Le 30/05/2019 Ã 14:43, casimiro.barreto(a)gmail.com a Ã©critÂ : > Recently installed (clear install). > > Apparently OSPluginWrapper.dll memory faulting. > Hi, I already got this problem and the only fix I know for now is to restart the computer. It is planned to improve the system command integration of Windows but for now, nobody got the time to work on it. But it's on the roadmap. > Windows 10 64bits > -- Cyril Ferlicot https://ferlicot.fr

May 30, 2019

Pharo Launcher failing in Windows 10

by casimiro.barreto＠gmail.com

Recently installed (clear install). Apparently OSPluginWrapper.dll memory faulting. Windows 10 64bits

May 30, 2019

Re: [Pharo-dev] Calypso idea - inherited tests

by Denis Kudriashov

Hi guys. Would be nice to see the error stack. Which variable is nil in that case? I really do not see such errors. Is it pharo 7 or 8? ÑÑ, 30 Ð¼Ð°Ñ 2019 Ð³., 11:17 ducasse <stepharo(a)netcourrier.com>: > > > On 29 May 2019, at 23:58, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Thu, 30 May 2019 at 06:26, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi Ben. >> >> There are already two features that support inherited tests: >> - run all tests using class icon: there will be extra red method group >> "broken tests" which will show failed inherited tests. >> - toggle inheritance visibility with checkbox in third panel: you will >> see inherited tests and standard method icon will run them. >> > > Ahh, excellent... the second is exactly what I wanted. > > Although using TestDelaySemaphoreSchedulerMicrosecondTicker as an example, > clicking on a test gives me an error "#selected was sent to nil" in > "ClyBrowserToolMorph>>isTabSelected" > Do you get the same? > > > Yes this happens to me often. > I think that calypso forks too many processes. > > > cheers -ben > > >

May 30, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Shaping

Using iceberg - I typically see the normal loading progress bars for long operations on the top left of the screen - often they stack below one another to show nested operations (aside: they are a bit ugly - but itâs a consistent metaphor across Pharo). I get them when loading, pulling, pushing, diffing etc. Do you not see them? I do, but not reliably. Sometimes I wait as I said until the loading threat is done. Then the GUI gets a chance to run, and the progress bar appears at the last moment (99% or so). Back to your version question - what baseline are you loading from a repo? A specific example might help. 7.0.3. It loaded after a fresh clone of pharo, but with a detached head. If i were to load Exercism as an example - the following page describes how to upgrade to a specific version of the baseline in the repo. Eg latest vs v0.2.3 https://github.com/exercism/pharo-smalltalk/blob/master/docs/UPGRADE.md This describes how to do it in the playground - as versions are actually loaded by metacello - and Iceberg builds on top of it to route things via git and make use of version tags etc, and it then gives the push/pull/commit operations. (Iâm probably describing this badly - but I suspect the confusion is in here for you). â¦ Hours later the âChecking out v7.0.3 from pharoâ progress bar is still stuck. How is the stuck progress bar related to the detached head? Having loaded your particular baseline (the code tagged as v2.0.3 for example), Iceberg will let you compare it to other branches - or hash versions in git. But typically, libraries you use will give you a playground script that specifies a stable version - you eval that in your playground and those libraries will then appear in your image (and also in Iceberg). Yes, I want all of Pharo 7.0.3 this time. I prefer to use one tool for versioning. Is that possible now in any version of Pharo? Can I use only Iceberg for all fetches and all commits? Or must I sometimes use evaluables like: Metacello new baseline: 'Exercism'; repository: 'github://exercism/pharo-smalltalk/releases/latest'; onConflict: [ :ex | ex allow ]; load. ? For your project - you can formalise those dependencies by creating your own baseline that references those scripts as well. Iâll do that once I get the basics working. The problems may be related to not using default install folders. Iâm not sure yet. Shaping On 30 May 2019, at 02:07, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: Sorry, I meant progress bar, not histoâ¦. From: Shaping [mailto:shaping@uurda.org] Sent: Wednesday, May 29, 2019 20:05 To: 'Pharo Development List' <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: RE: [Pharo-dev] Versioning with Iceberg From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: Wednesday, May 29, 2019 10:58 To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] Versioning with Iceberg On Wed, 29 May 2019 at 23:08, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: Iâm finding 7.0.3 to be more stable. How do I load a specific baseline/version with Iceberg? Iâm getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. There are many differences. I want to commit my image changes locally for now on a 7.0.3. Its not completely clear what you want. You can right-click a repo > Metacello > Install baseline of..... Or right-click a repo > Repository > Remotes and select one of those branches to check out. I missed the Repository item completely, all this time. I think I was blocking it out mentally because I was already in an Iceberg window that lists repos. The doubling up is confusing and unexpected. So we have Iceberg repos wrapping Git repos? Iâm not sure I have the scheme right. Why donât we have the usual wait-cursors appearing on long synchronous actions behind button clicks? These lock up the system for 1 or 2 minutes often. For example, I deleted 20-odd packages the other day and waited 2 minutes for it to finish, wondering why the system was completely unresponsive and showing no indication (no histo; no wait cursor). This happens when cloning a Git repo, too. The histo opens about Â½ second before the about 1-m pull finishes. This happened in the 7.0.3 build. Is there a policy not to use a wait-cursor if not histo is shown? Shaping

May 30, 2019