July 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Changing a BaselineOf... to include one more package

by Andrew Black

Iâve spent another couple of hours on this, and here is where I stand. I can get SmaCC-Reification to load if I use the "load ...â menu in the Montecello extension menu to Iceberg â but only if I select the fglr branch manually. (this is reasonable, because that group is not on the working branch) I canât get SmaCC-Reification to load as a dependency for Grace-Parser. Iâve tried pushing everything back to github. Iâve tried temporarily moving my git repos into the image directory (i.e., Iâve turned off the Iceberg setting to use a shared iceberg directory.) I still get > Could not resolve: BaselineOfSmaCC-Reification [BaselineOfSmaCC-Reification] in /Users/black/Development/Pharo/images/Pharo 7.0 SmallGrace 33/pharo-local/package-cache git@github.com:apblack/SmaCC.git[fglr] I get this message even after I have loaded SmaCC-Reification by hand. I donât know what else to try! My repo is on github: apblack/GraceInPharo. Iâm stranded until I can get this working. Andrew

July 21, 2018

Re: [Pharo-users] Changing a BaselineOf... to include one more package

by Andrew Black

> On 16 Jul 2018, at 07:27 , Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > - I've cloned SmaCC > - I've checked out the flgr branch > - I've loaded the baseline and added > >> spec package: 'SmaCC-Reification' with: [ spec requires: #('SmaCC-Smalltalk-Parser' 'SmaCC-Runtime' 'SmaCC-Java') ] > - then, I've done right click on the iceberg project and selected Metacello -> load baseline... => then inserted SmaCC-Reification and I got that package + dependencies loaded... Well, I thought that was what I did before. I tried this again, and â lo and behold â it worked! Thank you. > > > Moreover, my original problem is still there â it's looking in a nonexistent package cache, rather than on github, or in my ~/iceberg/apblack/SmaCC clone of github. > > I don't think this is quite like that... Metacello will try to lookup the package in several places. And it will check at last the package cache. So it fails because it was not able to found that package in any of your repositories, but the last it checked was the package cache. What still is not working is trying to reference SmaCC-Reficiation from baselineOfGrace. In `baselineOfGrace` Iâve put: spec package: 'Grace-Parser' with: [ spec requires: {'SmaCC' . 'SmaCC-Reification'. 'Grace-Scope'} ] but I still get the walkback > Could not resolve: BaselineOfSmaCC-Reification [BaselineOfSmaCC-Reification] in /Users/black/Development/Pharo/images/Pharo 7.0 SmallGrace 32/pharo-local/package-cache git@github.com:apblack/SmaCC.git[fglr] I took that message to mean that it was listing all the places that it had looked: first the non-existant package cache, and then githib. Is that wrong? Is it actually looking in my shared iceberg directory, but just not saying so? Does this only work after I have pushed everything to github? I like to get it working before I push. Andrew

July 21, 2018

Re: [Pharo-users] Status of Caffeine

by Siemen Baader

Ok, Thanks! :) Siemen Sent from my iPhone > On 20 Jul 2018, at 10.08, Craig Latta <craig(a)blackpagedigital.com> wrote: > > >> What about the UI lag and the occasional spinner that blocks the UI, >> is this related to the debugging protocol (I see that the IDEs are >> loaded in iframes) that will go away when run from local, or is this >> something that can be optimized away? > > That's just the speed of Morphic. The VM is set up to display the > spinner whenever anything takes more than a certain amount of time (one > alternative is to just turn it off :). While Morphic in SqueakJS has > gotten a lot faster since the first release, just because JavaScript > engines have gotten faster, I was still motivated to explore > alternatives. That's why I experimented with animated HTML wireframes, > morphic.js from Snap, and using a separate HMTL5 canvas for each morph. > > All three of these approaches are much faster than traditional > Morphic. However, the traditional Morphic UI has the appeal that it's > pixel-portable between the Web and native apps. > > > thanks again, > > -C > > -- > Craig Latta > Black Page Digital > Amsterdam :: San Francisco > craig(a)blackpagedigital.com > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) >

July 20, 2018

Re: [Pharo-users] Status of Caffeine

by Craig Latta

> What about the UI lag and the occasional spinner that blocks the UI, > is this related to the debugging protocol (I see that the IDEs are > loaded in iframes) that will go away when run from local, or is this > something that can be optimized away? That's just the speed of Morphic. The VM is set up to display the spinner whenever anything takes more than a certain amount of time (one alternative is to just turn it off :). While Morphic in SqueakJS has gotten a lot faster since the first release, just because JavaScript engines have gotten faster, I was still motivated to explore alternatives. That's why I experimented with animated HTML wireframes, morphic.js from Snap, and using a separate HMTL5 canvas for each morph. All three of these approaches are much faster than traditional Morphic. However, the traditional Morphic UI has the appeal that it's pixel-portable between the Web and native apps. thanks again, -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco craig(a)blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

July 20, 2018

Re: [Pharo-users] Status of Caffeine

by Siemen Baader

Very good! What about the UI lag and the occasional spinner that blocks the UI, is this related to the debugging protocol (I see that the IDEs are loaded in iframes) that will go away when run from local, or is this something that can be optimized away? Thanks for the details so far! Siemen On Thu, Jul 19, 2018 at 8:12 PM, Craig Latta <craig(a)blackpagedigital.com> wrote: > > > The minimal example seems to load fast enough. Do you think there is a > > potential to slim it down even further for a production system that > > uses the DOM as its UI, ie remove morphic and others and use the image > > in headless mode? > > Certainly. I've done some experiments with "animated wireframes" > for the development tools. See [1]. I can compose UIs in HTML, then read > them into SqueakJS and give them behavior by giving them DOM event > handlers written in Smalltalk. > > > Thanks for the offer to work together on the Pharo port. It is too > > early for me to commit to that, but I definitely like the idea. Right > > now I'm just checking out. I'd like to use Pharo's (or Squak's) > > interactive development workflow to develop single page web apps and > > mobile apps in a reliable manner. > > Yes, I've found it to be a very productive environment. It's great > to be able to debug things in situ, in the DOM environment. > > > Is there a way to run the IDE in a separate window from the actual > > application, so that the UI would behave as in production during > > development? I'm especially thinking of responsive web applications > > here. > > Yes; I've also built an interface to the Google remote debugging > protocol, so (in Chrome) I can run SqueakJS in one browser window, and > control whatever's going on in any other browser window. > > > (If not then perhaps putting them into divs next to each other might > > be a decent workaround) > > Yeah, this is what I did in the first Caffeine demo[2]. When I want > the Smalltalk IDE to disappear I just set the opacity of its div to zero > and its pointer-events to none. This approach works across all browsers. > > > thanks, > > -C > > [1] https://tinyurl.com/y9ngn363 (github.com) > [2] https://caffeine.js.org > > -- > Craig Latta > Black Page Digital > Amsterdam :: San Francisco > craig(a)blackpagedigital.com > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > >

July 19, 2018

Re: [Pharo-users] Status of Caffeine

by Craig Latta

> The minimal example seems to load fast enough. Do you think there is a > potential to slim it down even further for a production system that > uses the DOM as its UI, ie remove morphic and others and use the image > in headless mode? Certainly. I've done some experiments with "animated wireframes" for the development tools. See [1]. I can compose UIs in HTML, then read them into SqueakJS and give them behavior by giving them DOM event handlers written in Smalltalk. > Thanks for the offer to work together on the Pharo port. It is too > early for me to commit to that, but I definitely like the idea. Right > now I'm just checking out. I'd like to use Pharo's (or Squak's) > interactive development workflow to develop single page web apps and > mobile apps in a reliable manner. Yes, I've found it to be a very productive environment. It's great to be able to debug things in situ, in the DOM environment. > Is there a way to run the IDE in a separate window from the actual > application, so that the UI would behave as in production during > development? I'm especially thinking of responsive web applications > here. Yes; I've also built an interface to the Google remote debugging protocol, so (in Chrome) I can run SqueakJS in one browser window, and control whatever's going on in any other browser window. > (If not then perhaps putting them into divs next to each other might > be a decent workaround) Yeah, this is what I did in the first Caffeine demo[2]. When I want the Smalltalk IDE to disappear I just set the opacity of its div to zero and its pointer-events to none. This approach works across all browsers. thanks, -C [1] https://tinyurl.com/y9ngn363 (github.com) [2] https://caffeine.js.org -- Craig Latta Black Page Digital Amsterdam :: San Francisco craig(a)blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

July 19, 2018

Re: [Pharo-users] separate native window of same Pharo image

by kmo

I believe this is a known Windows issue. I have certainly seen it on my Windows machine at work. Doesn't happen on Linux. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 19, 2018

Re: [Pharo-users] separate native window of same Pharo image

by Peter UhnÃ¡k

Thank you both, this is exactly what I was looking for! But I ran into an issue (maybe this is Windows (10) specific): once I open the window, the original Pharo window is no longer responsive. It is not frozen, I can see a cursor blinking in the playground, but clicking anywhere or pressing any key doesn't do anything. This behavior persists even after I close the new window. Only when I press ctrl (without anything else) the content of the playground gets executed again, but that's it. I will try tomorrow on a different machine. Peter On Thu, Jul 19, 2018 at 6:22 PM, kmo <voxkmp(a)gmail.com> wrote: > Here's a screenshot of two roses windows being run from a pharo image in > another window <http://forum.world.st/file/t368903/roses.png> > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

July 19, 2018

Re: [Pharo-users] Status of Caffeine

by Siemen Baader

Hi Craig, Great, thanks! The minimal example seems to load fast enough. Do you think there is a potential to slim it down even further for a production system that uses the DOM as its UI, ie remove morphic and others and use the image in headless mode? Thanks for the offer to work together on the Pharo port. It is too early for me to commit to that, but I definitely like the idea. Right now I'm just checking out. I'd like to use Pharo's (or Squak's) interactive development workflow to develop single page web apps and mobile apps in a reliable manner. Is there a way to run the IDE in a separate window from the actual application, so that the UI would behave as in production during development? I'm especially thinking of responsive web applications here. (If not then perhaps putting them into divs next to each other might be a decent workaround) Cheers, Siemen Sent from my iPhone > On 19 Jul 2018, at 14.25, Craig Latta <craig(a)blackpagedigital.com> wrote: > > > > > Hi Siemen-- > >> What is the status of Caffeine now - is it production-ready with >> Pharo, and how large is a minimal (not development) image with >> everything required to run a production system - i.e. what would be >> the load time of a Caffeine web app? > > I'm using Caffeine in production with Squeak; there are a few bugs > to deal with in Pharo. Would you like to work together on it? > > A minimal system is a few hundred kilobytes, depending on the > application. The VR app I'm doing now is fairly large and loads in 10 > seconds. A small app should take about two seconds. The mini image demo > at [1] is a good approximation. > > Please feel free to join in on Caffeine issues, at [2]. > > > thanks, > > -C > > [1] https://squeak.js.org/demo/simple.html#fullscreen > [2] https://github.com/ccrraaiigg/ccrraaiigg.github.io/issues > > -- > Craig Latta > Black Page Digital > Amsterdam :: San Francisco > craig(a)blackpagedigital.com > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > >

July 19, 2018

Re: [Pharo-users] separate native window of same Pharo image

by kmo

Here's a screenshot of two roses windows being run from a pharo image in another window <http://forum.world.st/file/t368903/roses.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 19, 2018