- Pharo-users - lists.pharo.org

Rewrite Tool set in Spec2 changes

by Sebastian Jordan

Hi to all, Thanks to the received feedback, I made some changes on RewriteTool-Spec2. * First, when loading a rule a more detailed description of the rules is displayed on the RewriteRulesLoaderPresenter. * Also, I added several examples of Rewrite Rules. These rules are examples of common refactors that are made in Pharo. * Finally, when you open Match Tool from the Basic Rewrite Editor, the searchFor part of the rule is set to MatchTool pattern code. Screenshot of the new way to load a rule: https://imgur.com/gallery/Rp6Jfw2 The repo of the tool: https://github.com/jordanmontt/RewriteTool-Spec2 Thanks! Sebastian [https://i.imgur.com/X0TvS99.png?fb]<https://imgur.com/gallery/Rp6Jfw2> Rewrite Rule Loader<https://imgur.com/gallery/Rp6Jfw2> Imgur: The magic of the Internet imgur.com

Sept. 9, 2020

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by tbrunz

I think the "small hardware" market is another area where Pharo can make a good showing for itself, because it's small & relatively lightweight compared to others. So it makes good sense to me to couple Pharo with a similarly lightweight OS. I like the idea of "Pharo as OS + app on dedicated hardware", but doing it in the way of a "tiny Linux" OS for the VM to run with, rather than "let's make the VM into its own OS!" as has been suggested before -- because then you must code nearly everything in Pharo if you do that. (In the end, you would essentially end up incorporating the Linux kernel into the VM.) A compact Linux allows delegation of some tasks by the Pharo app to an existing Linux app. (At least until that app can be recoded in Pharo, of course. :^) -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 9, 2020

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by StÃ©phane Ducasse

Ted what I can tell you is that we are really interested in having Pharo more configurable (even from the VM point of view) to support better connection with small hardware os. The crew started to look at the protocols you mention :) And Iâm starting to look around for money to do a POC we will get back to you soon. S. > On 8 Sep 2020, at 22:49, tbrunz <wild.ideas(a)gmail.com> wrote: > > Offray Vladimir Luna CÃ¡rdenas-2 wrote >> I really like this idea of a minimal Linux distro that runs a minimal >> Pharo image that can be changed on demand according to different needs. >> It reminds me about some customized Linux distros I made in early >> 2000's, one called Scilix to package math packages for my undergrad >> students and after that, "Tangram Linux", which embraced the modular >> approach even more not only in its rebranding but mostly in its >> community dynamics to build modules (we used Morphix Linux at that time >> and FUSE file systems to package the modules and I even thought in using >> Puppy Linux as Debian/Ubuntu based ones became bigger). > > You can see one thing that has delayed my responses to you, Offray... ;^) > > I've been interested in minimal Linuxes for long time myself. Another very > nice one is *SliTaz Linux*, a 'roll your own' from Switzerland made by > Christophe Lincoln, et al. Very compact, but comes with a surprisingly > useful & usable set of applications that gives you a small, fast Linux that > can work as a 'daily driver'. > > Combining these with Pharo seems to make a lot of sense: Pharo is also > notably compact, and being able to essentially jettison the need for a > large, bloated OS to sit between it & hardware is intriguing. The original > Smalltalk was OS, IDE, and application all in one (running native on the > Alto 'personal computer'), so why shouldn't Pharo also include that heritage > by running as close to the hardware as practical? > > Running on a Linux is probably better than a VM that runs directly on 'bare > metal': You gain the ability to leverage Linux apps & services that don't > have to be duplicated in Pharo (or would be difficult, or don't exist & > there's no manpower for it, etc). > >> Running a modular Gnu/Linux with a modular Pharo suited for different >> devices could be really empowering, particularly in these pandemic times >> and the forecast of credible sources about having intermittent >> quarantines until 2024. > > Yes, there are all kinds of new possibilities that open up with this > concept. My background is device control for data acquisition and > closed-loop control systems. I have an "on the horizon" project to look > forward to: Building a set of Pharo uFFI bindings to provide an IDE that > will allow me/my team to build systems (including embedded/remote systems) > to monitor & control rack & stack instrumentation, custom hardware devices, > and distributed 'smart' controllers. > > One reason is to escape from expensive, proprietary development systems used > for this purpose. Another is to unlock the power of making custom web apps > to run these systems -- without getting tangled up in the complexities of > traditional web app development, JavaScript, CSS, etc. > >> Looking for connections between Pharo powered hardware and software, our >> approach here for the midterm under pandemic, has been re-enabling web >> publishing via IndieWeb[1], because I think that web presence will >> become more a more important as intermittent quarantine and physical >> ("social") distance stay with us. We want to empower solo merchants, >> small business, learners and educators to own their web presence and use >> it to connect better in times of forced distancing. We have not >> addressed the hardware part and I would bet for a mobile first approach >> using bots in popular chat networks like Telegram and smaller ones like >> Scuttlebutt[2] and Retroshare[3]. Its a pretty organic process run on a >> voluntary basis, so we value process over product and go without any >> rush. But seeing this hardware front makes me think about Raspad [4], >> Rasberry, recycled hardware and other low end devices as a practical >> approach for a more ubiquitous Pharo powered computing (and a wink to >> the Dynabook). > > There are several models of Chromebook that can also work this way, although > the Raspad is probably less expensive. Old Chromebooks that are no longer > having their ChromeOS updated can still be useful, running, e.g., GalliumOS. > And they're very inexpensive, since most will look at them as "throwaway" > items (and it's much better to recycle them instead). I've already > demonstrated Pharo running in GalliumOS, and am curious if TinyCore will run > on them as well. (I have an old Acer 720 to test with.) > >> [1] https://mutabit.com/repos.fossil/indieweb/ <https://mutabit.com/repos.fossil/indieweb/> >> [2] https://scuttlebutt.nz/ <https://scuttlebutt.nz/> >> [3] https://retroshare.cc/ <https://retroshare.cc/> >> [4] https://raspad.sunfounder.com/ <https://raspad.sunfounder.com/> >> >> Keep us updated on their experiments Ted. They seem pretty interesting. > > Thanks, Offray. I'll be posting what I learn, as I go... > > -t > >> Cheers, >> >> Offray >> >> Ps: On the Pharo 9.x front, once GT, Glamour and Spec1 are out, there >> will be something like the Playground with faceted exploring supported, >> like what we have now on Pharo 8.x? >> >> On 8/09/20 5:33 a. m., StÃ©phane Ducasse wrote: >>> I love it. >>> Now imagine with our specialised kernel or shrunk down versionâ¦ >>> We are preparing to >>> - remove a lot of code from Pharo 90 (spec1, eye inspector, GT, >>> Glamourâ¦.) >>> - but also to give the possibility to load on demand projects that we >>> are integrating and TESTING >>> - Microdown >>> - Roassal 30. >>> >>> S >>> >>>> On 8 Sep 2020, at 03:22, tbrunz < > >> wild.ideas@ > >> >> <mailto: > >> wild.ideas@ > >> >> wrote: >>>> >>>> This is running 32-bit Pharo 80 on 32-bit TinyCore 11.1 (Linux kernel >>>> 5.4.3). >>>> >>>> There is a 64-bit version of TinyCore, which I plan to test next... >>>> Then test 64-bit Pharo 80 and try Pharo Launcher on top of that. >>>> Then on a Raspberry Pi... >>>> >>>> Here's what's intriguing about this: >>>> >>>> TinyCore Linux is SUPER tiny -- 11MB for the headless 'Core' version, >>>> and >>>> 16MB for a FLTK/FLWM desktop. (Many different desktops are >>>> available.) The >>>> 'CorePlus' version (which I'm booted on) is still only 106MB; it >>>> supports >>>> Wifi & comes with installation tools & a variety of DEs to pick from. >>>> >>>> With TinyCore, you "build it the way you like it", by adding just the >>>> packages you want in your Linux image. With a stripped-down >>>> implementation, >>>> it's around the same size as the Pharo VM! >>>> >>>> Which makes TinyCore basically "a snap-on HAL module for the Pharo >>>> VM" that >>>> gives you what amounts to bare-metal operation -- and it can run 100% >>>> from >>>> RAM (as well as via mounting packages from persistent storage, on a >>>> package-by-package basis). >>>> >>>> You can persist TinyCore on disk, and keep your installed packages ("tce >>>> extensions") and your settings & user files persisted separately. That >>>> helps keep the TinyCore OS from being corrupted -- it's much like the >>>> '.image' file for Pharo; your changes are kept in a separate file. >>>> >>>> This opens up the possibility of making tiny/embedded little >>>> "appliances" >>>> that boot into TC, then auto-launch a Pharo image -- headless or with >>>> a UI, all without the burden of launching/maintaining full OS to do so. >>>> >>>> >>> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Sept. 9, 2020

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by tbrunz

Offray Vladimir Luna CÃ¡rdenas-2 wrote > I really like this idea of a minimal Linux distro that runs a minimal > Pharo image that can be changed on demand according to different needs. > It reminds me about some customized Linux distros I made in early > 2000's, one called Scilix to package math packages for my undergrad > students and after that, "Tangram Linux", which embraced the modular > approach even more not only in its rebranding but mostly in its > community dynamics to build modules (we used Morphix Linux at that time > and FUSE file systems to package the modules and I even thought in using > Puppy Linux as Debian/Ubuntu based ones became bigger). You can see one thing that has delayed my responses to you, Offray... ;^) I've been interested in minimal Linuxes for long time myself. Another very nice one is *SliTaz Linux*, a 'roll your own' from Switzerland made by Christophe Lincoln, et al. Very compact, but comes with a surprisingly useful & usable set of applications that gives you a small, fast Linux that can work as a 'daily driver'. Combining these with Pharo seems to make a lot of sense: Pharo is also notably compact, and being able to essentially jettison the need for a large, bloated OS to sit between it & hardware is intriguing. The original Smalltalk was OS, IDE, and application all in one (running native on the Alto 'personal computer'), so why shouldn't Pharo also include that heritage by running as close to the hardware as practical? Running on a Linux is probably better than a VM that runs directly on 'bare metal': You gain the ability to leverage Linux apps & services that don't have to be duplicated in Pharo (or would be difficult, or don't exist & there's no manpower for it, etc). > Running a modular Gnu/Linux with a modular Pharo suited for different > devices could be really empowering, particularly in these pandemic times > and the forecast of credible sources about having intermittent > quarantines until 2024. Yes, there are all kinds of new possibilities that open up with this concept. My background is device control for data acquisition and closed-loop control systems. I have an "on the horizon" project to look forward to: Building a set of Pharo uFFI bindings to provide an IDE that will allow me/my team to build systems (including embedded/remote systems) to monitor & control rack & stack instrumentation, custom hardware devices, and distributed 'smart' controllers. One reason is to escape from expensive, proprietary development systems used for this purpose. Another is to unlock the power of making custom web apps to run these systems -- without getting tangled up in the complexities of traditional web app development, JavaScript, CSS, etc. > Looking for connections between Pharo powered hardware and software, our > approach here for the midterm under pandemic, has been re-enabling web > publishing via IndieWeb[1], because I think that web presence will > become more a more important as intermittent quarantine and physical > ("social") distance stay with us. We want to empower solo merchants, > small business, learners and educators to own their web presence and use > it to connect better in times of forced distancing. We have not > addressed the hardware part and I would bet for a mobile first approach > using bots in popular chat networks like Telegram and smaller ones like > Scuttlebutt[2] and Retroshare[3]. Its a pretty organic process run on a > voluntary basis, so we value process over product and go without any > rush. But seeing this hardware front makes me think about Raspad [4], > Rasberry, recycled hardware and other low end devices as a practical > approach for a more ubiquitous Pharo powered computing (and a wink to > the Dynabook). There are several models of Chromebook that can also work this way, although the Raspad is probably less expensive. Old Chromebooks that are no longer having their ChromeOS updated can still be useful, running, e.g., GalliumOS. And they're very inexpensive, since most will look at them as "throwaway" items (and it's much better to recycle them instead). I've already demonstrated Pharo running in GalliumOS, and am curious if TinyCore will run on them as well. (I have an old Acer 720 to test with.) > [1] https://mutabit.com/repos.fossil/indieweb/ > [2] https://scuttlebutt.nz/ > [3] https://retroshare.cc/ > [4] https://raspad.sunfounder.com/ > > Keep us updated on their experiments Ted. They seem pretty interesting. Thanks, Offray. I'll be posting what I learn, as I go... -t > Cheers, > > Offray > > Ps: On the Pharo 9.x front, once GT, Glamour and Spec1 are out, there > will be something like the Playground with faceted exploring supported, > like what we have now on Pharo 8.x? > > On 8/09/20 5:33 a.Â m., StÃ©phane Ducasse wrote: >> I love it.Â >> Now imagine with our specialised kernel or shrunk down versionâ¦ >> We are preparing toÂ >> -Â remove a lot of code from Pharo 90 (spec1, eye inspector, GT, >> Glamourâ¦.) >> - but also to give the possibility to load on demand projects that we >> are integrating and TESTING >> - Microdown >> - Roassal 30.Â >> >> S >> >>> On 8 Sep 2020, at 03:22, tbrunz < > wild.ideas@ > >> <mailto: > wild.ideas@ > >> wrote: >>> >>> This is running 32-bit Pharo 80 on 32-bit TinyCore 11.1 (Linux kernel >>> 5.4.3). >>> >>> There is a 64-bit version of TinyCore, which I plan to test next... >>> Then test 64-bit Pharo 80 and try Pharo Launcher on top of that. >>> Then on a Raspberry Pi... >>> >>> Here's what's intriguing about this: Â >>> >>> TinyCore Linux is SUPER tiny -- 11MB for the headless 'Core' version, >>> and >>> 16MB for a FLTK/FLWM desktop. Â (Many different desktops are >>> available.) Â The >>> 'CorePlus' version (which I'm booted on) is still only 106MB; it >>> supports >>> Wifi & comes with installation tools & a variety of DEs to pick from. >>> >>> With TinyCore, you "build it the way you like it", by adding just the >>> packages you want in your Linux image. Â With a stripped-down >>> implementation, >>> it's around the same size as the Pharo VM! >>> >>> Which makes TinyCore basically "a snap-on HAL module for the Pharo >>> VM" that >>> gives you what amounts to bare-metal operation -- and it can run 100% >>> from >>> RAM (as well as via mounting packages from persistent storage, on a >>> package-by-package basis). >>> >>> You can persist TinyCore on disk, and keep your installed packages ("tce >>> extensions") and your settings & user files persisted separately. Â That >>> helps keep the TinyCore OS from being corrupted -- it's much like the >>> '.image' file for Pharo; your changes are kept in a separate file. >>> >>> This opens up the possibility of making tiny/embedded little >>> "appliances" >>> that boot into TC, then auto-launch a Pharo image -- headless or with >>> a UI, all without the burden of launching/maintaining full OS to do so. >>> >>> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 8, 2020

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by tbrunz

Still running on the netbook after 12 hours -- I'm writing this post on the TinyCore netbook, with Pharo Launcher & Pharo in the background. Here's some of the system stats: tc@box:~/pharo$ df -hT | grep -v tcloopFilesystem Type Size Used Available Use% Mounted onrootfs rootfs 1.7G 813.2M 978.3M 45% /tmpfs tmpfs 995.3M 91.1M 904.2M 9% /dev/shm/dev/sdb1 vfat 58.4G 55.1G 3.3G 94% /mnt/sdb1/dev/loop0 iso9660 27.0M 27.0M 0 100% /mnt/cdromtc@box:~/pharo$ uname -aLinux box 5.4.3-tinycore64 #2020 SMP Tue Dec 17 17:38:30 UTC 2019 x86_64 GNU/Linuxtc@box:~/pharo$ free -m total used free shared buff/cache availableMem: 1990 705 120 859 1165 198Swap: 482 46 436tc@box:~/pharo$ Next test will probably be an old Intel-powered Chromebook. (They can boot thumbdrives.) Then my RPi3. (It's a 3B model -- 64-bit ARMv8, but they're supposed to be backward-compatible with 32-bit ARMv7; there are TinyCore builds for ARMv6, ARMv7, and ARMv7l, so I'm not sure what will work there.)-t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 8, 2020

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by Offray Vladimir Luna CÃ¡rdenas

I really like this idea of a minimal Linux distro that runs a minimal Pharo image that can be changed on demand according to different needs. It reminds me about some customized Linux distros I made in early 2000's, one called Scilix to package math packages for my undergrad students and after that, "Tangram Linux", which embraced the modular approach even more not only in its rebranding but mostly in its community dynamics to build modules (we used Morphix Linux at that time and FUSE file systems to package the modules and I even thought in using Puppy Linux as Debian/Ubuntu based ones became bigger). Running a modular Gnu/Linux with a modular Pharo suited for different devices could be really empowering, particularly in these pandemic times and the forecast of credible sources about having intermittent quarantines until 2024. Looking for connections between Pharo powered hardware and software, our approach here for the midterm under pandemic, has been re-enabling web publishing via IndieWeb[1], because I think that web presence will become more a more important as intermittent quarantine and physical ("social") distance stay with us. We want to empower solo merchants, small business, learners and educators to own their web presence and use it to connect better in times of forced distancing. We have not addressed the hardware part and I would bet for a mobile first approach using bots in popular chat networks like Telegram and smaller ones like Scuttlebutt[2] and Retroshare[3]. Its a pretty organic process run on a voluntary basis, so we value process over product and go without any rush. But seeing this hardware front makes me think about Raspad [4], Rasberry, recycled hardware and other low end devices as a practical approach for a more ubiquitous Pharo powered computing (and a wink to the Dynabook). [1] https://mutabit.com/repos.fossil/indieweb/ [2] https://scuttlebutt.nz/ [3] https://retroshare.cc/ [4] https://raspad.sunfounder.com/ Keep us updated on their experiments Ted. They seem pretty interesting. Cheers, Offray Ps: On the Pharo 9.x front, once GT, Glamour and Spec1 are out, there will be something like the Playground with faceted exploring supported, like what we have now on Pharo 8.x? On 8/09/20 5:33 a.Â m., StÃ©phane Ducasse wrote: > I love it.Â > Now imagine with our specialised kernel or shrunk down versionâ¦ > We are preparing toÂ > -Â remove a lot of code from Pharo 90 (spec1, eye inspector, GT, Glamourâ¦.) > - but also to give the possibility to load on demand projects that we > are integrating and TESTING > - Microdown > - Roassal 30.Â > > S > >> On 8 Sep 2020, at 03:22, tbrunz <wild.ideas(a)gmail.com >> <mailto:wild.ideas@gmail.com>> wrote: >> >> This is running 32-bit Pharo 80 on 32-bit TinyCore 11.1 (Linux kernel >> 5.4.3). >> >> There is a 64-bit version of TinyCore, which I plan to test next... >> Then test 64-bit Pharo 80 and try Pharo Launcher on top of that. >> Then on a Raspberry Pi... >> >> Here's what's intriguing about this: Â >> >> TinyCore Linux is SUPER tiny -- 11MB for the headless 'Core' version, and >> 16MB for a FLTK/FLWM desktop. Â (Many different desktops are >> available.) Â The >> 'CorePlus' version (which I'm booted on) is still only 106MB; it supports >> Wifi & comes with installation tools & a variety of DEs to pick from. >> >> With TinyCore, you "build it the way you like it", by adding just the >> packages you want in your Linux image. Â With a stripped-down >> implementation, >> it's around the same size as the Pharo VM! >> >> Which makes TinyCore basically "a snap-on HAL module for the Pharo >> VM" that >> gives you what amounts to bare-metal operation -- and it can run 100% >> from >> RAM (as well as via mounting packages from persistent storage, on a >> package-by-package basis). >> >> You can persist TinyCore on disk, and keep your installed packages ("tce >> extensions") and your settings & user files persisted separately. Â That >> helps keep the TinyCore OS from being corrupted -- it's much like the >> '.image' file for Pharo; your changes are kept in a separate file. >> >> This opens up the possibility of making tiny/embedded little "appliances" >> that boot into TC, then auto-launch a Pharo image -- headless or with >> a UI, >> all without the burden of launching/maintaining full OS to do so. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.orgÂ > 03 59 35 87 52 > Assistant: Aurore DalleÂ > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley,Â > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France >

Sept. 8, 2020

Re: [Pharo-users] ported and refreshed Crypto-Nacl to GitHub (from StH)

by Jonathan van Alteren

Hi Torsten, Thanks for your message, those are some good questions/comments. 1. Looking at the frequency of the last commits on SmalltalkHub, I think I can step in as maintainer for the moment. Please let me know if you think something needs to be changed/added to the README to reflect that. 2. Although I am fine with making it more accessible to the community, I think it should not be integrated in the Cryptography repository. If I am correct, the Cryptography packages are a standalone, native implementation of ASN1 and several cryptography related libraries. Crypto-Nacl is a wrapper for Libsodium which uses uFFI, and will therefore only support features that Sodium offers. What are criteria for a repository to be placed under the pharo-contributions organization? 3. Thanks, I've updated the LICENSE file to add Tony and HernÃ¡n. 4. I changed the name earlier, but decided to revert to the original name in SmalltalkHub. If a name change is warranted, I think it should be libsodium-pharo, since the original NaCl library has been superseded by Sodium and other libsodium bindings follow a similar naming convention (seeÂ https://github.com/search?q=libsodium&type=Repositories) 5. Of course it would. At the moment, I only migrated the project from SmalltalkHub, refreshed a small bit of code and enabled smalltalkCI with GitHub Actions. Currently, you'd need to look at the tests for some examples. Any particular examples you would be interested in? Perhaps you can open an issue with a request. 6. It might already work on Windows, since the Nacl FFILibrary defines 'libsodium.dll' as win32 module (library) name. However, I don't currently run any Windows systems, so that would be a good opportunity for a contribution. Is that something you can help with? Thanks again for the feedback. I'm interested to work on this to gain more experience with maintaining an open source project, especially since this one doesn't seem very demanding at the moment. Are you familiar with Pieter Hintjens work and ideas on OS software? I find his C4 model (Collective Code Construction Contract) to be very interesting and I'm open to trying that out. See here for more context:Â https://hintjens.gitbooks.io/social-architecture/content/chapter4.html (The rest of the book is interesting as well.) Kind regards, Jonathan van Alteren Founding Member | Object Guild B.V. Sustainable Software for Purpose-Driven Organizations jvalteren(a)objectguild.com On 31 Aug 2020, 17:37 +0200, Torsten Bergmann , wrote: > Hi Jonathan, > > nice, thanks for investing time and effort into this. Such utilities are needed for serious applications. Some thoughts and questions: > > Â 1.Â What is the mid-term or long-term plan regarding collaboration? Will you be able to step in as maintainer? > > Â 2. As it already seems to be authored by several people and contains functionality of general interest it should beÂ considered to move it to > Â Â Â a central community place likeÂ https://github.com/pharo-contributions[https://github.com/pharo-contributio… where several people from community have already > Â Â Â access.Â It would then be in alignment withÂ https://github.com/pharo-contributions/Cryptography[https://github.com/phar… too and maintenance of > contributions as well as releases could be done from different sides and more centrally. > > Â Â Â You and anyone can then regulary fork from the community repo to an own (customized) repo like https://github.com/objectguild/Crypto-Nacl > > Â Â Â I guess Esteban can add you as contributor to "pharo-contribution" organization if you follow that path. > > Â 3. I guess LICENSE file need to be updated to give additionall credit to the original authors or mention more general "Pharo community" > Â Â Â (currently it mentionsÂ Object Guild solely) > > Â 4. Can it be changed to use "NaCl" instead of "Nacl" which is more suitable name for SodiumÂ (a similar name fixing was done in the Cuis port too) > > Â 5. Would it be possible to add some expressions/samples or docu in the README for end users on how to use it. This would give people a quick guide > on how to do things. > > Â 6. Any plans for making it work on Windows too? > > Thanks > Torsten > > > Gesendet:Â Montag, 31. August 2020 um 09:52 Uhr > Von:Â "Jonathan van Alteren" <jvalteren(a)objectguild.com> > An:Â "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Betreff:Â [Pharo-users] ported and refreshed Crypto-Nacl to GitHub (from StH) > > Hi all, > > I wanted to let you know that I ported the Crypto-Nacl library from SmalltalkHub to GitHub here:Â https://github.com/objectguild/Crypto-Nacl[https://github.com/objectguild/C… > > The original author is Tony Garnock-Jones, with contributions from HernÃ¡n Morales Durand. See the README for more details. > > Libsodium has evolved a lot over time, which means that there is plenty of additional functionality that can be unlocked through this library. I don't have a need for it at the moment, but that might change in the near future. My interest is in using the cryptographic features to enhance security of business applications. > > Oh, and thanks to the Buenos Aires Smalltalk team (https://github.com/ba-st/[https://github.com/ba-st/]) for inspiration on using GitHub Actions with smalltalkCI :-) > > > Cheers, > > Jonathan van Alteren > > Founding Member | Object Guild B.V. > Sustainable Software for Purpose-Driven Organizations > > jvalteren(a)objectguild.com >

Sept. 8, 2020

Re: [Pharo-users] Pharo on a Netbook running TinyCore Linux

by tbrunz

And it seems to be quite stable, too. I couldn't crash it (though I didn't try hard). I've had the 64-bit version of Pharo 8 running on TinyCorePure64-11.1 (out of RAM) for 8 hours now, and it's still working fine. Forums on TinyCore contain comments such as, "TC Linux embodies what is best in Linux. Fast, small, flexible, free and support for old hardware. And because its simple construction, it's almost indestructible." This really opens up possibilities for kiosks, embedded controllers, micro-controllers... And bootable thumb drives that you can just plug in, boot, and you have a Pharo running on your hardware. (When running solely in RAM, once it loads, you can remove the thumb drive.) -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 8, 2020

Re: [Pharo-users] Can it do this way ?

by Richard Sargent

On Tue, Sep 8, 2020, 04:35 Roelof Wobben via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Op 8-9-2020 om 08:30 schreef Roelof Wobben: > > Op 8-9-2020 om 04:22 schreef Richard O'Keefe: > > There are two quite different questions. > (1) Where may dashes occur in a real ISBN-10? > (2) What does Exercism require in the specification and check in the > test cases? > > For (1) the rules are > > Each ISBN consists of 5 elements with each section being separated by > spaces or hyphens. Three of the five elements may be of varying length: > > - *Prefix element* â currently this can only be either 978 or 979. It > is always 3 digits in length > - *Registration group element* â this identifies the particular > country, geographical region, or language area participating in the ISBN > system. This element may be between 1 and 5 digits in length > - *Registrant element* - this identifies the particular publisher or > imprint. This may be up to 7 digits in length > > > - *Publication element* â this identifies the particular edition and > format of a specific title. This may be up to 6 digits in length > - *Check digit* â this is always the final single digit that > mathematically validates the rest of the number. It is calculated using a > Modulus 10 system with alternate weights of 1 and 3. > > An ISBN-10 does not have the three-digit prefix. So we have > [0-9]{1,5} -- prefix > [0-9]{1,7} -- registrant > [0-9]{1,6} -- publication > [0-9X] > -- check digit > > As an examplw, "Standard C++ IOStreams and Locales" by Langer & Kreft has > ISBN-10 0-201-18395-1 > ISBN-13 9780201183955 > so I shall assume the separators are optional. > /^[0-9]{1,5}[- ]?[0-9]{1,7}[- ]?[0-9]{1,6}[- ]?[0-9X]$/ > Of course the elements cannot all have their maximum length at the same > time. In AWK I would write > x = a_putative_ISBN_10 > y = x > gsub(/[- ]+/, "", y) > if (x ~ /^[0-9]{1,5}[- ]?[0-9]{1,7}[- ]?[0-9]{1,6}[- ]?[0-9X]$/ \ > && y ~ /^[0-9]{9,9}[0-9X]$/ \ > ) { > x *might* be valid, we still need to check the checksum > } > > For (2), there appear to be no restrictions on where dashes may occur > or how many: "These may be communicated with or without hyphens". > Exercism doesn't allow spaces. > > Regular expressions are elegant in their own way, BUT for this problem > they are (a) excessive, (b) inefficient, and (c) insufficient. > > digit count := 0. > check sum := 0. > for each character c of the string > if c is not a hyphen then > if c is a digit then > digit value := c's value as a digit > else if c is X and digit count = 9 then > digit value := 10 > else > return false. > digit count := digit count + 1. > if digit count > 10 then return false. > check sum := (11 - digit count) * digit value + check sum. > return check sum mod 11 is zero. > > Part of the insight here is "don't DO it, just PRETEND you did." > That is, instead of copying the string without the hyphens, > just ignore the hyphens as they turn up. > Another part is "if you are only going to use it once, don't store it." > That is, we need a digit's value just once, in the update to check sum, > so we should compute it just before we need it, not store it. > > Now the pseudo-code above is classic sequential imperative coding. > > Classic functional coding does something like > let no_dashes = filter (/= '-') (explode string) in > length no_dashes = 10 and > let check = last no_dashes in > (is_digit check or check = 'X') and > all is_digit (take 9 no_dashes) and > let xval c = if x = 'X' then 10 else digit_value c in > dot (map xval no_dashes) [10,9..1]) mod 11 = 0 > > This pseudo-code translates nicely to Smalltalk too. > You might want to add > > SequenceableCollection>> > with: other inject: initial into: aBlock > |r| > r := initial. > self with: other do: [:x :y | > r := aBlock value: r value: x value: y]. > ^r > dot: other > ^self with: other inject: 0 into: [:acc :x :y | x*y + acc] > > (These methods are so obvious that it would be absurd to claim > any intellectual property rights to them.) > > I also have "fusion" methods like > SequenceableCollection>> > from: start to: finish allSatisfy: testBlock > self from: start to: finish do: [:each | > (aBlock value: each) ifFalse: [^false]]. > ^true > > so that ((seq copyFrom: a to: z) allSatisfy: blk) > can be done as (seq from: a to: z allSatisfy: blk) > without making a copy. > > Fusion methods are useful because Smalltall compilers > don't work as hard at eliminating intermediate data > structures as functional language compilers. (Having > other priorities.) > > (isdigit (last no_dashes > return false if digit count > 10. > > > > > Thanks for letting me see this. > But still I wonder if this is really the OOP way and if that function does > more then 1 thing. > It looks to me that its iterating trrough the string. Calculating the crc > and checking it. > I learned that it is a good thing that a function and a class does only 1 > thing. > > Roelof > > > I learned on other oop languages that for mainibility it's needed that a > class does one thing and a method does also one thing. > So when software changes , you can easily make the changes. Its I think > called SOLID and I like that idea. > So I try to make that also work in Pharo but it seems not so important. > It's look like me that getting it work is more important. > I don't think that is the case here. Identify the objects involved in an ISBN string. I see String and Character. Once parsed, you could have an ISBN itself, with the elements cited by Richard O'keefe. But the exercise isn't about that, but only about the validation. There is very little behaviour that one could add to String and Character that would help in this exercise and that would be appropriate to their respective roles. Arguably, you could solve this exercise by creating a parser. I think that would be a lot like using a 10 pound sledge hammer to install a thumbtack. > > Roelof > >

Sept. 8, 2020

Re: [Pharo-users] Can it do this way ?

by Roelof Wobben

Sept. 8, 2020