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

Re: [Pharo-users] Pharo 7 file streams guideline

by Richard O'Keefe

I am a little confused by Filestreams.MD #position and #position: report and set the number of past items. So when you open a stream, #position is 0. So why does the first "Positionable streams" example use ... position: 4 ... while the second one skips 3 characters? ... position: 3 ... would be just as broken. Oh, I think a clarification is needed when talking about UTF-8. To the best of my knowledge you don't need a Byte-Order-Mark at the beginning of a UTF-8 stream because there is no byte order issue to result, but apparently many Windows programs like to add one. Does/will Pharo add one when writing a UTF-8 file? Does/will it skip one when reading a UTF-8 file? I find the new approach produces unattractive code. I can do all of the examples simply in a system that (a) implements the ANSI Smalltalk FileStream class methods (b) supports '/dev/stdin' and '/dev/stdout' as file names (c) interprets the external type #'text' either as #'utf8' or as "whatever $LC_CTYPE says" and also supports #'utf8' and #'cp1250' as external types. Oh, and defines Object>>bindOwn: aBlock ^(self respondsTo: #close) ifTrue: [aBlock ensure: [self close]] ifFalse: [aBlock value] What document should I read to get a mental model of the new system and understand its rationale? On 23 July 2018 at 19:38, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hello, > > I've prepared a draft of a short document that should help you with the > transition to the "new" file streams API in Pharo 7. > > https://github.com/pavel-krivanek/pharoMaterials/blob/ > master/Filestreams.MD > > Pull requests are welcome. > > Cheers, > -- Pavel > > > >

July 23, 2018

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

by Sean P. DeNigris

Andrew Black-2 wrote >> spec >> baseline: 'SmaCC' with: [ spec loads: #('Reification' ) ] > > Can you tell me what this line actually means. That is, what does the > #baseline:with: method actually declare? It means load the 'Reification' group of the SmaCC project, as specified in BaselineOfSmaCC. The 'Reification' group includes the SmaCC-Reification package, and by extension its dependencies as specified by the baseline. Andrew Black-2 wrote > Where should I put this statement? In baselineOfSmaCC, or > baselineOfGrace? Why? baselineOfGrace. You're saying that SmaCC (specifically the Reification group) is a dependency of Grace. You should probably also add Smacc the the #requires: list of whatever (e.g. package(s)) requires it. Deep into Pharo (http://books.pharo.org/deep-into-pharo/) Chapter 9 gives a pretty good explanation of much of Metacello. Ignore the gopher stuff which has been replaced by the Metacello scripting API. Also, the book was written when baseline methods were in Configuration classes, whereas now for git they are reified into BaselineOf classes, but the API of the actual method is still the same so it should help clarify. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 23, 2018

Re: [Pharo-users] Grease stream tests failing on Pharo7

by Richard O'Keefe

(ReadWriteStream on: 'abc') contents ==> 'abc' in GNU Smalltalk and Dolphin ==> '' in Squeak 6.0 and ST/X Here I think we see why ANSI Smalltalk defined #with: for {Read,}WriteStreams but not #on:. When you recall that ReadWriteStream is a subclass of WriteStream in most Smalltalks, and that (WriteStream on: (String new: 20)) or whatever is normally used with the argument of #on: expected to provide *workspace*, not *content*, why on earth would you expect (ReadWriteStream on: 'abc') contents to be different from (WriteStream on: 'abc') contents which is ''? On 23 July 2018 at 21:50, Johan Brichau <johan(a)inceptive.be> wrote: > Hi, > > As Iâm diving into the changes and why it fails: > > (ReadWriteStream on: âabcâ) contents > -> = âabcâ on Pharo 6 > -> = ââ on Pharo 7 > > That seems wrong to me. > > (Iâve also sent this question via github on the commit itself > https://github.com/pharo-project/pharo/commit/ > 9e442addff3790af0c78dbc73f1f349de8a4ad03#diff- > ba7cc7962a4a22468a18b31fe75ada04 ) > > cheers > Johan > > On 22 Jul 2018, at 10:52, Johan Brichau <johan(a)inceptive.be> wrote: > > Hi, > > I am taking a look at making Grease and Seaside work correctly on Pharo7. > > There have been a number of changes to the ReadWriteStream implementation > in Pharo that break Grease tests: https://travis-ci.org/ > SeasideSt/Grease/jobs/406766720 > It seems ReadWriteStream is broken: the readLimit is almost always wrong > meaning that the stream `atEnd`, `contents` etc.. return wrong values > > Before I dive into this, I wanted to inquire if anyone is working on this > as I cannot seem to find any open cases on this on the issue tracker. > > cheers > Johan > > > >

July 23, 2018

Re: [Pharo-users] [ANN] Cryptography package on github

by Sean P. DeNigris

Esteban A. Maringolo wrote > Good work Norbert. Thanks! +1 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 23, 2018

Re: [Pharo-users] [ANN] Cryptography package on github

by Esteban A. Maringolo

Good work Norbert. Thanks! Esteban A. Maringolo El lun., 23 jul. 2018 a las 8:59, Norbert Hartl (<norbert(a)hartl.name>) escribiÃ³: > > After several attempts to solve the Cryptography package problems over the years I decided to move it on my own to github. > > What I did: > > - researched all authors and used the git migration tool to get the package from smalltalkhub to github > - released a version 0.1 that should be exactly the same as the code on smalltalkhub for people that want to change > - fixed an occurrence of IfNotNilDo: in the Cryptography package to make it load in pharo7 > - added a metacello baseline > - added a group âall" that loads everything like it is now with one package > - added travis files and enable travis checks for pull requests > - released a version 0.2 that contains the original code plus travis and metacello > - Started to cut off the ASN1, PKCS12 and X509 classes in separate packages > - Added to each new package a -Tests package containing tests > - constructed all dependencies in the baseline > - added a core group that loads the now slimmed down package solely > > I must say this was really great with the help of promote-demote package tag functionality and the dependency browser. The only thing missing is kind of a tool to construct the metacello baseline. I miss Versionner here. > > What I didnât do: > > - checking all the other packages in the repo. There are packages with old style ffi calls and things that seem to be squeak dependent. > > I hope with the time and peopleâs complaints we can figure out what is obsolete and what needs to be adjusted. > > The repository is now at > > https://github.com/zweidenker/Cryptography > > but Iâm happy to move it to a better place if someone has an idea. > > Pull requests and tickets are welcome. > > Hope you like it, > > Norbert >

July 23, 2018

[ANN] Cryptography package on github

by Norbert Hartl

After several attempts to solve the Cryptography package problems over the years I decided to move it on my own to github. What I did: - researched all authors and used the git migration tool to get the package from smalltalkhub to github - released a version 0.1 that should be exactly the same as the code on smalltalkhub for people that want to change - fixed an occurrence of IfNotNilDo: in the Cryptography package to make it load in pharo7 - added a metacello baseline - added a group âall" that loads everything like it is now with one package - added travis files and enable travis checks for pull requests - released a version 0.2 that contains the original code plus travis and metacello - Started to cut off the ASN1, PKCS12 and X509 classes in separate packages - Added to each new package a -Tests package containing tests - constructed all dependencies in the baseline - added a core group that loads the now slimmed down package solely I must say this was really great with the help of promote-demote package tag functionality and the dependency browser. The only thing missing is kind of a tool to construct the metacello baseline. I miss Versionner here. What I didnât do: - checking all the other packages in the repo. There are packages with old style ffi calls and things that seem to be squeak dependent. I hope with the time and peopleâs complaints we can figure out what is obsolete and what needs to be adjusted. The repository is now at https://github.com/zweidenker/Cryptography <https://github.com/zweidenker/Cryptography> but Iâm happy to move it to a better place if someone has an idea. Pull requests and tickets are welcome. Hope you like it, Norbert

July 23, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Sven Van Caekenberghe

> On 23 Jul 2018, at 09:38, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hello, > > I've prepared a draft of a short document that should help you with the transition to the "new" file streams API in Pharo 7. > > https://github.com/pavel-krivanek/pharoMaterials/blob/master/Filestreams.MD > > Pull requests are welcome. > > Cheers, > -- Pavel Great contribution, thanks ! I see no factual errors, everything is clear, cookbook style. The last two sections might be more confusing than helpful. I would go more for 'all streams are buffered, don't worry' and 'beware positioning is byte based'. Regarding positioning, some additional points that might no be so well known. - Positioning in a variable length encoded stream is plain hard (and basically comes down to linear searching) - All ZnCharacterEncoders understand #backOnStream: that does the right thing - There is also ZnPositionableReadStream that can help (read the class comment) Sven

July 23, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Sven Van Caekenberghe

> On 23 Jul 2018, at 11:13, Ben Coman <btc(a)openinworld.com> wrote: > > On 23 July 2018 at 15:38, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Hello, >> >> I've prepared a draft of a short document that should help you with the >> transition to the "new" file streams API in Pharo 7. >> >> https://github.com/pavel-krivanek/pharoMaterials/blob/master/Filestreams.MD >> >> Pull requests are welcome. >> >> Cheers, >> -- Pavel >> >> >> > > Some discussion prior to any pull request (and while I'm away from > Pharo machine) > > I like all the new code examples until "Write a UTF-8 text to STDOUT" > and I wonder "Stdio stdout writeStreamDo: [ :stream | stream > nextPutAll: 'a â b' ]" would better fit the pattern of the other new > code. > (presuming "Stdio stdout" returns a FileReference, oherwise maybe > "Stdio stdoutRef" or "Stdio stdout asFileReference") Stdio stdout and friends just return a binary stream, hence they need wrapping for encoding. Maybe Stdio stdoutAsText might be an idea, but this is so uncommon that I am not sure this is a good idea. > Under "Positionable streams", rather than needing "3 timesRepeat: [ > stream next ]" > would it be worth having #utf8position: to more intention revealing? no more new API, please. Positioning in a variable length encoded stream is plain hard - see my other mail. > cheers -ben >

July 23, 2018

Re: [Pharo-users] Grease stream tests failing on Pharo7

by Johan Brichau

Hi, As Iâm diving into the changes and why it fails: (ReadWriteStream on: âabcâ) contents -> = âabcâ on Pharo 6 -> = ââ on Pharo 7 That seems wrong to me. (Iâve also sent this question via github on the commit itself https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f3… <https://github.com/pharo-project/pharo/commit/9e442addff3790af0c78dbc73f1f3…> ) cheers Johan > On 22 Jul 2018, at 10:52, Johan Brichau <johan(a)inceptive.be> wrote: > > Hi, > > I am taking a look at making Grease and Seaside work correctly on Pharo7. > > There have been a number of changes to the ReadWriteStream implementation in Pharo that break Grease tests: https://travis-ci.org/SeasideSt/Grease/jobs/406766720 <https://travis-ci.org/SeasideSt/Grease/jobs/406766720> > It seems ReadWriteStream is broken: the readLimit is almost always wrong meaning that the stream `atEnd`, `contents` etc.. return wrong values > > Before I dive into this, I wanted to inquire if anyone is working on this as I cannot seem to find any open cases on this on the issue tracker. > > cheers > Johan > >

July 23, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Ben Coman

On 23 July 2018 at 15:38, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hello, > > I've prepared a draft of a short document that should help you with the > transition to the "new" file streams API in Pharo 7. > > https://github.com/pavel-krivanek/pharoMaterials/blob/master/Filestreams.MD > > Pull requests are welcome. > > Cheers, > -- Pavel > > > Some discussion prior to any pull request (and while I'm away from Pharo machine) I like all the new code examples until "Write a UTF-8 text to STDOUT" and I wonder "Stdio stdout writeStreamDo: [ :stream | stream nextPutAll: 'a â b' ]" would better fit the pattern of the other new code. (presuming "Stdio stdout" returns a FileReference, oherwise maybe "Stdio stdoutRef" or "Stdio stdout asFileReference") Under "Positionable streams", rather than needing "3 timesRepeat: [ stream next ]" would it be worth having #utf8position: to more intention revealing? cheers -ben

July 23, 2018

Pharo 7 file streams guideline

by Pavel Krivanek

Hello, I've prepared a draft of a short document that should help you with the transition to the "new" file streams API in Pharo 7. https://github.com/pavel-krivanek/pharoMaterials/blob/master/Filestreams.MD Pull requests are welcome. Cheers, -- Pavel

July 23, 2018

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

by Andrew Black

> On 22 Jul 2018, at 19:35 , Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Andrew Black-2 wrote >>> spec >>> baseline: 'SmaCC-Reification' >>> with: [ spec repository: 'github://apblack/SmaCC:fglr' ]. > > This line will not work. What you're saying here is load a BaselineOfXyz > where Xyz = 'SmaCC-Reification'. In fact you want to load the package. I > think you can just change the keyword #basline: to #package:, although SmaCC > has a 'Reification' group, which might be better. In any event, if you just > want to make sure that the 'SmaCC-Reification' package is loaded when you > load SmaCC, then I think what you're after is: > spec > baseline: 'SmaCC' with: [ spec loads: #('Reification' ) ] > > I think the above would replace both of your SmaCC-related lines (you can > specify multiple entities in to #loads: if needed. > > NB. the preferred syntax in a baseline is literal arrays like above i.e. #() > instead of curly-brace runtime arrays like {'Grace-Tests' . 'Grace-Ast'} > Thanks for the suggestions. But now I am more confused than ever! Can you tell me what this line actually means. That is, what does the #baseline:with: method actually declare? Where should I put this statement? In baselineOfSmaCC, or baselineOfGrace? Why? Note that the SmaCC-Reification package is not part of the current normal load for SmaCC â thatâs why I have to specify it separately. Is this declaration saying the opposite? If not, what is it saying? Earlier, you wrote: >> spec package: 'SmaCC-Reification' with: [ spec requires: >> #('SmaCC-Smalltalk-Parser' 'SmaCC-Runtime' 'SmaCC-Java') ] AFAICT this is not necessary because these dependencies are declared in BaselineOfSmaCC. These declarations are the very lines from baselineOfSmaCC that declare these dependencies â arenât they? If I take them out, how will Metacello know that loading SmaCC-Reification requires the three packages listed in the array? Iâm sorry if I sound frustrated â none of this makes any sense to me. There seems to be no documentation other than the very high-level stuff that describes th eoverall purpose of package dependencies â which I think that I understand. Andrew

July 23, 2018

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

by Sean P. DeNigris

Andrew Black-2 wrote >> spec >> baseline: 'SmaCC-Reification' >> with: [ spec repository: 'github://apblack/SmaCC:fglr' ]. This line will not work. What you're saying here is load a BaselineOfXyz where Xyz = 'SmaCC-Reification'. In fact you want to load the package. I think you can just change the keyword #basline: to #package:, although SmaCC has a 'Reification' group, which might be better. In any event, if you just want to make sure that the 'SmaCC-Reification' package is loaded when you load SmaCC, then I think what you're after is: spec baseline: 'SmaCC' with: [ spec loads: #('Reification' ) ] I think the above would replace both of your SmaCC-related lines (you can specify multiple entities in to #loads: if needed. NB. the preferred syntax in a baseline is literal arrays like above i.e. #() instead of curly-brace runtime arrays like {'Grace-Tests' . 'Grace-Ast'} ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 23, 2018

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

by Sean P. DeNigris

Guillermo Polito wrote >> But then I must also specify the dependencies of the SmaCC-Reification >> package, so I need to add >> >> spec package: 'SmaCC-Reification' with: [ spec requires: >> #('SmaCC-Smalltalk-Parser' 'SmaCC-Runtime' 'SmaCC-Java') ] AFAICT this is not necessary because these dependencies are declared in BaselineOfSmaCC. In fact the whole point of Metacello is that you can refer just to the specific entity within a project you want to load and Metacello should take care of bringing along all its dependencies. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 23, 2018

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

by Andrew Black

> On 21 Jul 2018, at 08:22 , Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Andrew P. Black wrote >> I donât know what else to try! > > From the error message: > Could not resolve: BaselineOfSmaCC-Reification... in > https://github.com/apblack/SmaCC.git[working] > > I'm guessing that you can't load from two different branches of the same git > repo. Can you fork the project and create a new branch that merges in the > required changes from the 'working' and 'fglr' branches? Good trysuggestion Sean. I think that there may indeed be some brokenness in the way that Pharo uses git, so that the branch spec in the baseline is not always obeyed. So I switched both of the dependencies to be on the same branch (fglr), and for good measure switched my local repo to also be on that branch. > spec > baseline: 'SmaCC' > with: [ spec repository: 'github://apblack/SmaCC:fglr' ]. > spec > baseline: 'SmaCC-Reification' > with: [ spec repository: 'github://apblack/SmaCC:fglr' ]. The result? Nothing changes. I still get a complaint 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] In the git directory I can see > silverstone: ~/iceberg/apblack/SmaCC$ ls -d SmaCC-Reification.package/ > SmaCC-Reification.package/ > silverstone: ~/iceberg/apblack/SmaCC$ git br > * fglr > ... Is it supposed to be looking for `BaselineOfSmaCC-Reification` rather than for `SmaCC-Reification`? There is no `BaselineOfSmaCC-Reification`, just a `BaselineOfSmaCC` that defines a group called `SmaCC-Refication`. (I did try replacing baseline: âSmaCC-Reificationâ by group: âSmaCC-Reificationâ , but that gave a different error.) Andrew

July 23, 2018

Dynabook concept

by Hilaire

Some reflexions on the Dynabook concept: http://blog.drgeo.eu/post/2018/The-Dynabook-Concept Hilaire -- Dr. Geo http://drgeo.eu

July 22, 2018

Re: [Pharo-users] Mac OS X left/right scrolling in Pharo issues

by Manuel Leuenberger

July 22, 2018

Grease stream tests failing on Pharo7

by Johan Brichau

Hi, I am taking a look at making Grease and Seaside work correctly on Pharo7. There have been a number of changes to the ReadWriteStream implementation in Pharo that break Grease tests: https://travis-ci.org/SeasideSt/Grease/jobs/406766720 <https://travis-ci.org/SeasideSt/Grease/jobs/406766720> It seems ReadWriteStream is broken: the readLimit is almost always wrong meaning that the stream `atEnd`, `contents` etc.. return wrong values Before I dive into this, I wanted to inquire if anyone is working on this as I cannot seem to find any open cases on this on the issue tracker. cheers Johan

July 22, 2018

Mac OS X left/right scrolling in Pharo issues

by wyattbiker

Is there a way to disable the mouse left/right side scroll when using the Pharo IDE. It causes unwanted highlights or mouse cursor movements. I think it simulates SHIFT + right/left arrow keys. I am using a Magic Mouse but also the trackpad has same problem. Here in this example, the sidescroll actually scrolls thru the tabs of the Inspector. <http://forum.world.st/file/t369021/Screen_Shot_2018-07-21-1.png> In the browser or playground it moves and highlights randomly. <http://forum.world.st/file/t369021/Screen_Shot_2018-07-21-2.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 21, 2018

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

by Sean P. DeNigris

Andrew P. Black wrote > I donât know what else to try! >From the error message: Could not resolve: BaselineOfSmaCC-Reification... in https://github.com/apblack/SmaCC.git[working] I'm guessing that you can't load from two different branches of the same git repo. Can you fork the project and create a new branch that merges in the required changes from the 'working' and 'fglr' branches? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 21, 2018

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