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

Re: [Pharo-users] Bit Manipulation Challenge

by David T. Lewis

On Tue, Jul 21, 2020 at 02:17:59AM +0800, Ben Coman wrote: > On Mon, 20 Jul 2020 at 23:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > I want to take an IP address routing prefix in CIDR [1] notation (i.e. the 24 > > in "192.168.100.14/24") and convert it into subnet form (i.e. > > 255.255.255.0). I came up with 4 ways to do that (see below), but none stand > > out as best (although #3 and #4 seem a bit more straightforward as they > > avoid the `max` temp). > > > > How would you go about it? > > > > Here are the ways I came up with: > > cidr := 24. > > shift := 32 - cidr. > > max := #[ 255 255 255 255 ] asInteger. > > "1." ((max bitShift: shift negated) bitShift: shift) asByteArray. > > "2." (max bitClear: (2 raisedTo: shift) - 1) asByteArray. > > "3." ((2 raisedTo: shift) - 1) bitInvert32 asByteArray. > > "4." (((2 raisedTo: cidr) - 1) bitShift: shift) asByteArray > > To me the most complicated ones have the "subtract 1" - it makes it > harder to reason about. I'd also guess "3" and "4" are slowest. > > "1." can be simplified by hardcoding max.... > 5. (4294967295 bitShift: shift negated) bitShift: shift) asByteArray > > Additional alternative... > 6. ((4294967295 bitShift: shift) rem: 4294967296) asByteArray > > And why not low-brow... > 7. CIDRLookup at: cidr. > > cheers -ben This also seems to work for IPV4: (max << shift) asByteArray last: 4 Dave

July 20, 2020

[ANN] Willow-Bootstrap v12.1.1 [v12.1.1] released!

by Buenos Aires Smalltalk

July 20, 2020

[ANN] RenoirSt v7.0.2 [v7.0.2] released!

by Buenos Aires Smalltalk

July 20, 2020

Re: [Pharo-users] Bit Manipulation Challenge

by Ben Coman

On Mon, 20 Jul 2020 at 23:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I want to take an IP address routing prefix in CIDR [1] notation (i.e. the 24 > in "192.168.100.14/24") and convert it into subnet form (i.e. > 255.255.255.0). I came up with 4 ways to do that (see below), but none stand > out as best (although #3 and #4 seem a bit more straightforward as they > avoid the `max` temp). > > How would you go about it? > > Here are the ways I came up with: > cidr := 24. > shift := 32 - cidr. > max := #[ 255 255 255 255 ] asInteger. > "1." ((max bitShift: shift negated) bitShift: shift) asByteArray. > "2." (max bitClear: (2 raisedTo: shift) - 1) asByteArray. > "3." ((2 raisedTo: shift) - 1) bitInvert32 asByteArray. > "4." (((2 raisedTo: cidr) - 1) bitShift: shift) asByteArray To me the most complicated ones have the "subtract 1" - it makes it harder to reason about. I'd also guess "3" and "4" are slowest. "1." can be simplified by hardcoding max.... 5. (4294967295 bitShift: shift negated) bitShift: shift) asByteArray Additional alternative... 6. ((4294967295 bitShift: shift) rem: 4294967296) asByteArray And why not low-brow... 7. CIDRLookup at: cidr. cheers -ben

July 20, 2020

Bit Manipulation Challenge

by Sean P. DeNigris

I want to take an IP address routing prefix in CIDR [1] notation (i.e. the 24 in "192.168.100.14/24") and convert it into subnet form (i.e. 255.255.255.0). I came up with 4 ways to do that (see below), but none stand out as best (although #3 and #4 seem a bit more straightforward as they avoid the `max` temp). How would you go about it? Here are the ways I came up with: cidr := 24. shift := 32 - cidr. max := #[ 255 255 255 255 ] asInteger. "1." ((max bitShift: shift negated) bitShift: shift) asByteArray. "2." (max bitClear: (2 raisedTo: shift) - 1) asByteArray. "3." ((2 raisedTo: shift) - 1) bitInvert32 asByteArray. "4." (((2 raisedTo: cidr) - 1) bitShift: shift) asByteArray 1. https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 20, 2020

[ANN] Pharo Launcher 2.2 released!

by Christophe Demarey

Hi all, Pharo Launcher 2.2 has just been released! It is available from http://pharo.org/download. It is mostly a bug fix release but it comes with some enhancements. Full log is available at https://github.com/pharo-project/pharo-launcher/releases/tag/2.2 and https://github.com/pharo-project/pharo-launcher/releases/tag/2.1 (not announced, was buggy). Regards > Le 17 avr. 2020 Ã 18:08, Christophe Demarey <christophe.demarey(a)inria.fr> a Ã©crit : > > Hi all, > > Pharo Launcher 2.0 has just been released! It is available from http://pharo.org/download <http://pharo.org/download>. > > This new version introduces major changes: > The UI has been fully rewritten using the new Spec2 framework <https://github.com/pharo-spec/Spec> and the Commander2 library <https://github.com/pharo-spec/Commander2>. UI has been revamped to increase usability, especially for newcomers. The main window is now composed of a toolbar and the list of images. The template list is now available when clicking on the new image button. > Documentation web site : All Pharo Launcher features are now explained in the new documentation available at https://pharo-project.github.io/pharo-launcher <https://pharo-project.github.io/pharo-launcher>. You can contribute easily by clicking the *edit on GitHub* button. > You can now have many launch configurations for an image (VM to use, vm and image arguments). It means you can use headless Pharo VM from Pharo Launcher. > When creating a new image, you can specify an initialisation script that will be run once at the first image launch. It is useful to load your project code in a stock Pharo image for example. See https://pharo-project.github.io/pharo-launcher/create-images/#image-initial… <https://pharo-project.github.io/pharo-launcher/create-images/#image-initial…> > You can now define your own template sources in addition to official sources (see https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-l… <https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-l…>), including authenticated sources. > Improved image metadata. Pharo Launcher now manages all image metadata in a single STON file (including description, Pharo version). > > Big thanks to all contributors, including issue reports. It is also the opportunity to thanks Damien Cassou, the original author of Pharo Launcher. > > Here is the changelog: > Pharo Launcher v2.0 <https://github.com/pharo-project/pharo-launcher/releases/tag/2.0> > > The list of closed issue is too long (68) to be listed but you can browse it here: https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Acl… <https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Acl…> > Here are some highlights: > New features: > > Documentation web site > Image initialisation script > Launch configurations, headless VM support > User template file in addition to the official template file > Jenkins server template now support pipeline projects > Support of private Jenkins server > Support of authenticated HTTP server > Improvements: > > Monitoring of image launch failures to give back the error message (if any) > Newly created image is automatically selected in the image list > Allow to set image description at creation time > Better error management (you will have the choice to ignore them or debug them) > Add a poor version column in image list > Speedup (especially when image repository has a lot of images) > > Bug fixes: > > Fix use of system unzip on Windows > > Regards, > The Pharo team.

July 20, 2020

Re: [Pharo-users] UFFI asynchronous callbacks

by tesonep＠gmail.com

Hi, as Ben correctly pointed out there is the alternative of using a Queue based approach for FFI. It is available as a plugin for the headless VM and it can be used with Pharo 8. It is here: https://github.com/pharo-project/threadedFFI-Plugin The plugin is already compiled and shipped with the VM. It is only required to load the Smalltalk side code with: Metacello new baseline: 'ThreadedFFI'; repository: 'github://pharo-project/threadedFFI-Plugin'; onConflictUseLoaded; load. This is fully integrated as a backend of UFFI, so all the code you already have it will be working fine. You need to give more information to select the callout strategy to use (https://github.com/pharo-project/threadedFFI-Plugin/wiki/Using-with-UFFI) Using TFFI it is possible to receive callbacks from other threads and process them in the VM thread. If you need any help, please feel free to ask in the list, so it can be useful for everybody. Cheers, Pablo On Sun, Jul 19, 2020 at 6:32 PM Ben Coman <btc(a)openinworld.com> wrote: > > Hi Asam, > > On Sun, 19 Jul 2020 at 21:38, ASAM <vmax28575(a)gmail.com> wrote: > > > > Hello Ben, > > > > I quickly made a dummy DLL to limit the problem to the essentials. > > Great idea. A more generic example is attractive for people to > examine and help out. > I browsed the code but I'm sorry it needs a deeper expertise than I have. > Hopefully someone working on the threaded FFI will tune in. > > In the meantime, it won't solve your query but you may find this > interesting to watch... > Strategies for Non-Blocking FFI > https://www.youtube.com/watch?v=L_QFwsNOMAc > > cheers -ben > > > > > I think my problem comes more from how I use the semaphore. > > > > I wanted to do that: > > > > only "semaphore signal", > > But that somehow doesn't work. > > Now i'm doing that "[ Processor yield. semaphore signal ] fork" (it work's) > > but i don't know if that's a good idea. > > > > > > ffiCallback > > ^ FFICallback signature: #( void #( uint32 foo ) ) block: [ :foo | > > Transcript > > show: 'API Funktion value: ' , foo asString, ' activePriority:', > > Processor activePriority asString; cr. > > > > "that's working" > > [ Processor yield. semaphore signal ] fork. > > > > "that usually works 80%." > > "[ semaphore signal ] fork" > > > > "that crashes pharo almost always." > > "semaphore signal" > > ] > > > > I also have a little problem, too. Why can I use my own C-Type UNUM32 at > > ...self ffiCall: #( T_ERROR StartMyThreadFunction(UNUM32 millisecondsToFire) > > ). > > But with FFICallback signature: # (void # (uint32 foo)) I get an error > > "Unable to resolve external type: UNUM32. Why is that? > > > > Thanks for your help. > > > > testDllForAsyncCallback.dll > > <http://forum.world.st/file/t372350/testDllForAsyncCallback.dll> > > testDllForAsyncCallback.cpp > > <http://forum.world.st/file/t372350/testDllForAsyncCallback.cpp> > > testDllForAsyncCallback.h > > <http://forum.world.st/file/t372350/testDllForAsyncCallback.h> > > testDllForAsyncCallback.h > > <http://forum.world.st/file/t372350/testDllForAsyncCallback.h> > > UFFICallback.st <http://forum.world.st/file/t372350/UFFICallback.st> > > CTypes.st <http://forum.world.st/file/t372350/CTypes.st> > > <http://forum.world.st/file/t372350/Transcript.png> > > > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > -- Pablo Tesone. tesonep(a)gmail.com

July 20, 2020

Re: [Pharo-users] Iceberg: Installing a baseline from a self hosted Git/Gitea repository branch

by Offray Vladimir Luna CÃ¡rdenas

Thanks a lot Christophe! It worked like a charm. Now I'm able to build a shareable installation baseline that uses external git repositories not hosted in the oligopolistic providers by downloading them with Iceberg and loading from the hard disk with Metacello. I have updated the Grafoscopio readme with the new installation procedure[1] [1] https://mutabit.com/repos.fossil/grafoscopio/doc/tip/readme.md.html Now, as I'm using that pattern for almost all my baselines (as they're not hosted on GitHub, GitLab or Bitbucked), I would like to create some kind of Metacello "plugin" that extends its vocabulary to load several repositories in that way. I will be using a Pharo MOOC lesson from Stephan where he extended numbers to understand tabletop RPG vocabulary, but with Pharo 8. I wouldn't mind to host this on GitHub to make it easily loadable, as it would open the door to any non-GitHub repository and I will share the "plugin" here. Maybe it can be made a part of official Metacello. My point is that this short and key explanation inspires me to learn how to collaborate in more core technologies behind Pharo and to share my plans, advances and questions. So, thanks again. Cheers, Offray On 16/07/20 4:24 p.Â m., Christophe Demarey wrote: > Hi Offray, > > You can also use something like: > location := FileLocator localDirectory / 'iceberg' / 'pharo-contributions' / 'taskit'. > (IceRepositoryCreator new > location: location; > remote: (IceGitRemote url: 'https://github.com/pharo-contributions/taskit.git'); > createRepository) > register. > > Metacello new > repository: 'gitlocal://', location fullName; > baseline: 'TaskIt'; > load > > Regards, > Christophe > >> Le 16 juil. 2020 Ã 20:04, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> a Ã©crit : >> >> Hi Pierce, >> >> I'm loading the stuff in the self Gitea repositories from local copies >> and in the order I know they are needed. So in a sense I following a >> similar behavior as yours (but I will use the `tonel:///` trick now when >> needed, thanks for it). >> >> My problem is with sharing my baseline with others to ease their >> installation of the packages I develop, without using Git oligopolistic >> providers (GitHub, GitLab and Bitbucket), but instead self hosted >> community Gitea instances. >> >> From this thread, I imagine that the path to follow is to extend the >> Metacello Git providers to include Gitea instances. I will see how the >> current ones are implemented and what can I contribute using them as a >> template for new providers and see how to contribute this back to Pharo >> as a Metacello "plugin". I will share advances and questions here. >> >> Cheers, >> >> Offray >> >> On 15/07/20 10:19 p. m., Pierce Ng wrote: >>> On Wed, Jul 15, 2020 at 08:41:04AM -0500, Offray Vladimir Luna CÃ¡rdenas wrote: >>>> So, a better question would be: Is possible to load programatically (via >>>> a code snippet) using Iceberg, Monticello or something else a baseline >>>> that installs a project and its dependencies and is hosted in an >>>> independent Git provider? How can self hosted git repositories >>>> containing baselines be loaded? >>> Hi Offray, >>> >>> I don't define dependencies in baselines for stuff in my self-hosted >>> Gitea because I work on them myself and I know their interdependencies. >>> And since I am working on them, they are all locally checked out. >>> >>> I load my stuff in the correct order like this: >>> >>> Metacello new >>> baseline: 'StuffOne'; >>> repository: 'tonel:///home/pierce/work/git/StuffOne/src'; >>> load. >>> >>> Metacello new >>> baseline: 'StuffTwo'; >>> repository: 'tonel:///home/pierce/work/git/StuffTwo/src'; >>> load. >>> >>> Here StuffTwo is dependent on StuffOne. To be clear, I have written >>> baselines for StuffOne and StuffTwo, which is how I am loading them >>> here. I'm just not defining in StuffTwo's baseline that StuffOne is a >>> dependency. >>> >>> For me this is more agile because I only need to edit my load snippet >>> and I get immediate feedback by running it. The Git repo roundtripping >>> of fixing up dependencies in baselines OTOH feels more like the >>> edit-compile-test cycle. Eventually if/when I publish StuffOne and >>> StuffTwo, I do have to define the dependencies but it'll be easy because >>> then they'll be on Github. >>> >>> Pierce >>> >>> >> >

July 19, 2020

Re: [Pharo-users] UFFI asynchronous callbacks

by Ben Coman

Hi Asam, On Sun, 19 Jul 2020 at 21:38, ASAM <vmax28575(a)gmail.com> wrote: > > Hello Ben, > > I quickly made a dummy DLL to limit the problem to the essentials. Great idea. A more generic example is attractive for people to examine and help out. I browsed the code but I'm sorry it needs a deeper expertise than I have. Hopefully someone working on the threaded FFI will tune in. In the meantime, it won't solve your query but you may find this interesting to watch... Strategies for Non-Blocking FFI https://www.youtube.com/watch?v=L_QFwsNOMAc cheers -ben > > I think my problem comes more from how I use the semaphore. > > I wanted to do that: > > only "semaphore signal", > But that somehow doesn't work. > Now i'm doing that "[ Processor yield. semaphore signal ] fork" (it work's) > but i don't know if that's a good idea. > > > ffiCallback > ^ FFICallback signature: #( void #( uint32 foo ) ) block: [ :foo | > Transcript > show: 'API Funktion value: ' , foo asString, ' activePriority:', > Processor activePriority asString; cr. > > "that's working" > [ Processor yield. semaphore signal ] fork. > > "that usually works 80%." > "[ semaphore signal ] fork" > > "that crashes pharo almost always." > "semaphore signal" > ] > > I also have a little problem, too. Why can I use my own C-Type UNUM32 at > ...self ffiCall: #( T_ERROR StartMyThreadFunction(UNUM32 millisecondsToFire) > ). > But with FFICallback signature: # (void # (uint32 foo)) I get an error > "Unable to resolve external type: UNUM32. Why is that? > > Thanks for your help. > > testDllForAsyncCallback.dll > <http://forum.world.st/file/t372350/testDllForAsyncCallback.dll> > testDllForAsyncCallback.cpp > <http://forum.world.st/file/t372350/testDllForAsyncCallback.cpp> > testDllForAsyncCallback.h > <http://forum.world.st/file/t372350/testDllForAsyncCallback.h> > testDllForAsyncCallback.h > <http://forum.world.st/file/t372350/testDllForAsyncCallback.h> > UFFICallback.st <http://forum.world.st/file/t372350/UFFICallback.st> > CTypes.st <http://forum.world.st/file/t372350/CTypes.st> > <http://forum.world.st/file/t372350/Transcript.png> > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

July 19, 2020

Re: [Pharo-users] UFFI asynchronous callbacks

by ASAM

Hello Ben, I quickly made a dummy DLL to limit the problem to the essentials. I think my problem comes more from how I use the semaphore. I wanted to do that: only "semaphore signal", But that somehow doesn't work. Now i'm doing that "[ Processor yield. semaphore signal ] fork" (it work's) but i don't know if that's a good idea. ffiCallback ^ FFICallback signature: #( void #( uint32 foo ) ) block: [ :foo | Transcript show: 'API Funktion value: ' , foo asString, ' activePriority:', Processor activePriority asString; cr. "that's working" [ Processor yield. semaphore signal ] fork. "that usually works 80%." "[ semaphore signal ] fork" "that crashes pharo almost always." "semaphore signal" ] I also have a little problem, too. Why can I use my own C-Type UNUM32 at ...self ffiCall: #( T_ERROR StartMyThreadFunction(UNUM32 millisecondsToFire) ). But with FFICallback signature: # (void # (uint32 foo)) I get an error "Unable to resolve external type: UNUM32. Why is that? Thanks for your help. testDllForAsyncCallback.dll <http://forum.world.st/file/t372350/testDllForAsyncCallback.dll> testDllForAsyncCallback.cpp <http://forum.world.st/file/t372350/testDllForAsyncCallback.cpp> testDllForAsyncCallback.h <http://forum.world.st/file/t372350/testDllForAsyncCallback.h> testDllForAsyncCallback.h <http://forum.world.st/file/t372350/testDllForAsyncCallback.h> UFFICallback.st <http://forum.world.st/file/t372350/UFFICallback.st> CTypes.st <http://forum.world.st/file/t372350/CTypes.st> <http://forum.world.st/file/t372350/Transcript.png> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 19, 2020