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

Re: [Pharo-users] How to modify a non-forked Iceberg repository to create a pull request

by Esteban Maringolo

Thank you Gabriel. It was even simpler. Esteban A. Maringolo On Sat, Jul 27, 2019 at 5:37 PM Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > Forth the repo > Add the remote > And just push to your remote > Then use the usual flow for pr > > On Sat, Jul 27, 2019, 16:33 Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> I was working on something using Glorp, loaded as a Metacello >> dependency cloned directly from the pharo-rdbms/Glorp GitHub repo. >> >> Then I found what I think is a bug, make a few modifications and make >> created a new commit. >> >> I cannot commit to the `origin` remote since I'm not a member, but I >> can't create a pull request, because I started from the "upstream" >> repo as my base. >> >> What should be the way to solve this without losing the local changes >> (commited but not pushed)? >> >> I thought: >> - Fork the pharo-rdbms/Glorp repository in my own GitHub user >> - Add a new remote (via CLI) to my Glorp local (pharo) >> repositorypointing to the one at my user (emaringolo/Glorp). >> - Fetch and checkout from the remote pointing to my repository >> - Merge my local changes into my repository >> - Push my changes >> - Create a pull request from eMaringolo/Glorp to pharo-rdbms/Glorp >> >> Is this wrong? What do you suggest? >> I think this might happen to anyone who started working on some >> repository that is not a fork of the canonical and then tries to make >> changes to it. >> >> Regards, >> >> Esteban A. Maringolo >>

July 27, 2019

Re: [Pharo-users] How to modify a non-forked Iceberg repository to create a pull request

by Gabriel Cotelli

Forth the repo Add the remote And just push to your remote Then use the usual flow for pr On Sat, Jul 27, 2019, 16:33 Esteban Maringolo <emaringolo(a)gmail.com> wrote: > I was working on something using Glorp, loaded as a Metacello > dependency cloned directly from the pharo-rdbms/Glorp GitHub repo. > > Then I found what I think is a bug, make a few modifications and make > created a new commit. > > I cannot commit to the `origin` remote since I'm not a member, but I > can't create a pull request, because I started from the "upstream" > repo as my base. > > What should be the way to solve this without losing the local changes > (commited but not pushed)? > > I thought: > - Fork the pharo-rdbms/Glorp repository in my own GitHub user > - Add a new remote (via CLI) to my Glorp local (pharo) > repositorypointing to the one at my user (emaringolo/Glorp). > - Fetch and checkout from the remote pointing to my repository > - Merge my local changes into my repository > - Push my changes > - Create a pull request from eMaringolo/Glorp to pharo-rdbms/Glorp > > Is this wrong? What do you suggest? > I think this might happen to anyone who started working on some > repository that is not a fork of the canonical and then tries to make > changes to it. > > Regards, > > Esteban A. Maringolo > >

July 27, 2019

How to modify a non-forked Iceberg repository to create a pull request

by Esteban Maringolo

I was working on something using Glorp, loaded as a Metacello dependency cloned directly from the pharo-rdbms/Glorp GitHub repo. Then I found what I think is a bug, make a few modifications and make created a new commit. I cannot commit to the `origin` remote since I'm not a member, but I can't create a pull request, because I started from the "upstream" repo as my base. What should be the way to solve this without losing the local changes (commited but not pushed)? I thought: - Fork the pharo-rdbms/Glorp repository in my own GitHub user - Add a new remote (via CLI) to my Glorp local (pharo) repositorypointing to the one at my user (emaringolo/Glorp). - Fetch and checkout from the remote pointing to my repository - Merge my local changes into my repository - Push my changes - Create a pull request from eMaringolo/Glorp to pharo-rdbms/Glorp Is this wrong? What do you suggest? I think this might happen to anyone who started working on some repository that is not a fork of the canonical and then tries to make changes to it. Regards, Esteban A. Maringolo

July 27, 2019

Re: [Pharo-users] Personal Programming

by Richard O'Keefe

There are some spelling issues in the PDF one finds at the Newton-Raphson link. "bellow" and "below" mean different things and sound quite different (BELL-owe vs b'-LOW). In "In the sketch bellow" the one you want is "below". "bloc" and "block" sound the same but also mean different things, and the Smalltalk [...] forms are "blocks" not "blocs". Is writing these interactive documents as much work as it looks like? On Sat, 27 Jul 2019 at 17:59, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi Trygve, > > Personal programming is something I always been fascinated by, since > decades, to empower users. > > In the domain of teaching, the concept can go as far as giving the > ability to teachers to craft their own numeric tools in their respective > area. > > This is for this exact reason I ported DrGeo to Squeak, then Pharo, in > 2005. The end user programming gives the power to design very advanced > teaching models[1]. > > However, Smalltalk scripting can be tricky, so this is with profound > interest I will read your paper in the later days. > > Hilaire > > [1] http://blog.drgeo.eu/post/2019/The-Newton-Raphson-Method > > Le 25/07/2019 Ã 11:29, Trygve a Ã©crit : > > The final draft of my magnum opus about Personal Programming is now > > ready for review: > > http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf > > -- > Dr. Geo > http://drgeo.eu > > > >

July 27, 2019

[ANN] Pharo Newsletter July 2019

by Marcus Denker

The Pharo Newsletter July 2019 has been sent to subscribers one week ago. https://mailchi.mp/pharo/pharo-newsletter-july-2019 <https://mailchi.mp/pharo/pharo-newsletter-july-2019> To get it as soon as it is released, please subscribe here: http://eepurl.com/bykqWn <http://eepurl.com/bykqWn>

July 27, 2019

Re: [Pharo-users] Personal Programming

by Hilaire

Hi Trygve, Personal programming is something I always been fascinated by, since decades, to empower users. In the domain of teaching, the concept can go as far as giving the ability to teachers to craft their own numeric tools in their respective area. This is for this exact reason I ported DrGeo to Squeak, then Pharo, in 2005. The end user programming gives the power to design very advanced teaching models[1]. However, Smalltalk scripting can be tricky, so this is with profound interest I will read your paper in the later days. Hilaire [1] http://blog.drgeo.eu/post/2019/The-Newton-Raphson-Method Le 25/07/2019 Ã 11:29, Trygve a Ã©critÂ : > The final draft of my magnum opus about Personal Programming is now > ready for review: > http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf -- Dr. Geo http://drgeo.eu

July 27, 2019

Re: [Pharo-users] P7 regression

by Hilaire

Not at the same time on the same file. #put:into is use in one situation to write out a sketch as a XML file, and in another situation to write out a PNG image. However, It is true DrGeo xml document can embed bitmap, but it is base64 encoded, so saving with readStream is not a problem. I am still curious how I will use wrappedStream inÂ case DrGeo's XML document contained binary data. Le 26/07/2019 Ã 08:03, Sven Van Caekenberghe a Ã©critÂ : > You said you wanted to write both character data (XML) as binary data (images) to the same stream, or so I understood. > >> On 26 Jul 2019, at 00:22, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> I don't understand how #wrappedStream works in my situation? >> >> Is #isBinary not good enougth? >> >> Le 25/07/2019 Ã 21:53, Sven Van Caekenberghe a Ã©crit : >>> If you have a character read or write stream, you can use #wrappedStream to access the underlying binary stream, should you need to do that. >>> >>>> On 25 Jul 2019, at 20:31, Hilaire <hilaire(a)drgeo.eu> wrote: >>>> >>>> Thanks for the tips. It is definitely a left over from porting DrGeo to >>>> P7 from P4/5/6 (not sure) >>>> >>>> But it can't really work as put:into: is used to write both sktech >>>> content (XML file) and its PNG preview. >>>> >>>> At some point in Pharo history both UTF8 and bitmap were using binary >>>> stream. >>>> >>>> Likely a putBinary:into: is needed too. >>>> >>>> -- >>>> Dr. Geo >>>> http://drgeo.eu >>>> >>>> >>>> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> > -- Dr. Geo http://drgeo.eu

July 26, 2019

Re: [Pharo-users] Personal Programming

by Trygve

I dream of a future with the release of a Loke 1.0 that is firmly embedded in Pharo. A Loke that is quickly becoming the computing environment of choice for millions of homeowners and schoolchildren. Trygve On 25.07.2019 18:34, CÃ©drick BÃ©ler wrote: > Me too ! > > And on the huge esug discussion points to have ^^ > > Cheers, > > Cedrick > > > Le 25 juil. 2019 Ã 13:09, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> a Ã©critÂ : > >> Looks very interesting! I will read it (it arrives just in time to be >> part of the holiday reading pileâ¦) >> >> Marcus >> >>> On 25 Jul 2019, at 11:29, Trygve <trygver(a)ifi.uio.no >>> <mailto:trygver@ifi.uio.no>> wrote: >>> >>> Dear all, >>> The final draft of my magnum opus about Personal Programming is now >>> ready for review: >>> http://folk.uio.no/trygver/themes/Personal/PP-019%20-%20Copy%20(17).pdf >>> >>> The article's main theme is Personal Programming for everybody with >>> /Loke/, a personal object computer. Its first purpose is to empower >>> laypeople to take control over their corner of the Net with its IoT. >>> I have created a proof-of-concept implementation as a non-intrusive >>> extension of Squeak version 3.10.2, and have used it to demonstrate >>> how a novice uses the Loke IDE to create a small and intuitive program. >>> >>> The article describes the concepts behind Loke .The current Squeak >>> implementation should be ported to Pharo and can grow into the >>> preferred Pharo-based IDE for laypeople taking control over their >>> information environment. >>> >>> I will appreciate your possible comments before Aug. 31. >>> Enjoy >>> --Trygve >>> >>> The article's 43 pages has several high points, I have included one >>> of them here: >>> ----------- begin extract ------------------ >>> >>> >>> C.7.We need a paradigm shift >>> >>> The history of Western astronomy shows a series of paradigm shifts >>> from the geocentric paradigm with its stationary Earth as the center >>> of the Universe with its epicycles and other bizarre explanations of >>> what appeared to be essential complexities. Astronomy evolved via >>> the heliocentric to the current distributed paradigm with its chunks >>> of mass connected by gravity. What appeared as essential complexity >>> in one paradigm was easily resolved in the next. >>> >>> It is tempting to look for similar paradigm shifts in computing. >>> Mainstream programming has based much of its theory and practice on >>> the CPU-centric paradigm exemplified by the von Neumann machine. A >>> memory-centric paradigm came in 1960 with the Autokon CAC/ CAM >>> system and its central database (Reenskaug, 1973). The solution was >>> obvious, and there must have been many similar initiatives without >>> me being aware of them. >>> >>> It is time to realize that the first two paradigms do not meet our >>> current challenges: We are plagued with immensely large, complex, >>> and insecure systems that long ago left the realm of human >>> understanding. A recent example: Customers found that their bank >>> charged them twice for the same transaction. Several weeks after the >>> problem was discovered, the bank publicly admitted that they still >>> didn't understand how the problem could arise: The complexity of >>> their system was clearly beyond human comprehension. The bank has a >>> staff of very competent experts, but they need a better foundation >>> for modeling and implementing their sophisticated requirements. >>> >>> Computers can transform, store, and communicate data, (Figure >>> below). The essence of the CPU-centric paradigm is that computers >>> are primarily used to transform data; they compute. The essence of >>> the memory-centric paradigm is that computers are used primarily to >>> store data; they organize applications around a shared database. The >>> essence of the communication-centric paradigm is that computers are >>> primarily used to exchange messages with other computers to make >>> them collaborate to achieve a common goal. >>> >>> /The three paradigms of computing // >>> //<pbeopicbehdhbfmc.png>/ >>> It is time to heed Tony Hoare's plea for simplicity and achieve a >>> better way of separating concerns. Mainstream programming should >>> shift to the communication-centric paradigm exemplified by the >>> object computer that is the foundation for this article. >>> >>> The communication-centric paradigm has been on the horizon for many >>> years. I first met it in Prokon's idea of distributed computers >>> (Reenskaug, 1977), but there must have been many other initiatives. >>> A newer example is Service-Oriented Architectures (SOA) that, in >>> essence, is communication-centric. It didn't meet with immediate >>> success, possibly because people tried to apply it within the >>> CPU-centric paradigm where it doesn't belong. There are many other >>> examples such as distributed computing. And of course, DCI and the >>> IoT itself are, by definition, communication-centric. >>> >>> ----------- end extract ------------------ >>> >>> >>> >> -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info NorwayÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Tel: (+47) 22 49 57 27

July 26, 2019

Re: [Pharo-users] P7 regression

by Sven Van Caekenberghe

You said you wanted to write both character data (XML) as binary data (images) to the same stream, or so I understood. > On 26 Jul 2019, at 00:22, Hilaire <hilaire(a)drgeo.eu> wrote: > > I don't understand how #wrappedStream works in my situation? > > Is #isBinary not good enougth? > > Le 25/07/2019 Ã 21:53, Sven Van Caekenberghe a Ã©crit : >> If you have a character read or write stream, you can use #wrappedStream to access the underlying binary stream, should you need to do that. >> >>> On 25 Jul 2019, at 20:31, Hilaire <hilaire(a)drgeo.eu> wrote: >>> >>> Thanks for the tips. It is definitely a left over from porting DrGeo to >>> P7 from P4/5/6 (not sure) >>> >>> But it can't really work as put:into: is used to write both sktech >>> content (XML file) and its PNG preview. >>> >>> At some point in Pharo history both UTF8 and bitmap were using binary >>> stream. >>> >>> Likely a putBinary:into: is needed too. >>> >>> -- >>> Dr. Geo >>> http://drgeo.eu >>> >>> >>> >> > -- > Dr. Geo > http://drgeo.eu > > >

July 26, 2019

Re: [Pharo-users] P7 regression

by Hilaire

I don't understand how #wrappedStream works in my situation? Is #isBinary not good enougth? Le 25/07/2019 Ã 21:53, Sven Van Caekenberghe a Ã©critÂ : > If you have a character read or write stream, you can use #wrappedStream to access the underlying binary stream, should you need to do that. > >> On 25 Jul 2019, at 20:31, Hilaire <hilaire(a)drgeo.eu> wrote: >> >> Thanks for the tips. It is definitely a left over from porting DrGeo to >> P7 from P4/5/6 (not sure) >> >> But it can't really work as put:into: is used to write both sktech >> content (XML file) and its PNG preview. >> >> At some point in Pharo history both UTF8 and bitmap were using binary >> stream. >> >> Likely a putBinary:into: is needed too. >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> > -- Dr. Geo http://drgeo.eu

July 25, 2019