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

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

by Sean P. DeNigris

David T. Lewis wrote > FFI based solutions work at a different level of abstraction than > VM plugins, and there is a role for both. Thanks for the context, David. Now that we understand the different niches, the main problem is that they can not be loaded in the same image without breaking :/ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 23, 2018

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

by Sean P. DeNigris

Mariano Martinez Peck wrote > From what I understand/remember/believe, the main reasons for > building OSSubprocess were: Thanks, Mariano!! Very informative :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 23, 2018

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

by Mariano Martinez Peck

Hi guys, First, I would like to say that David was always very helpful, positive and we have discussed and worked together a lot for this. When I was sponsored to build OSSubprocess I already got the "we would like this have this", so maybe some additional opinion from the ESUG board may help clarify. From what I understand/remember/believe, the main reasons for building OSSubprocess were: 1) *FFI-based tool*. Low the barrier of having to modify the VM to make a fix. Despite all our efforts, we still have way more people able to deal with FFI than with the VM. Even more if the VM is now shared under a common project, in which is not always easy to plug Pharo-specific stuff. 2) *Cleaner/nicer API*. You may or may not agree with this and that's perfect (we all have different opinions). When I was using OSProcess I always thought the API was not as I would like to, so my goal was to provide a API closer to my wishes. Again, not necessary better. 3) *Smaller functionality than OSProcess*: OSProcess is huge...it allows you to fork squeak images, fork() + exec*() whatever you want, runs on Windows, etc. We wanted something smaller...just enough to be able to fork processes. That is... to capture the most common/easy process forking.. But if you really need something very advance, you may still go to bare metals and use OSProcess approach (fork + exec). 4) *Added infrastructure*. We wanted the project to be on Git, with a very detailed documentation, very high test coverage, and CI integration. ----- So...that is about the reasons... as to why it breaks when OSProcess is loaded to, it's because for OSSubprocess I took the wonderful idea from OSProcess of the child reaper. This is a process that runs on the Smalltalk side and handles exception (via semaphore) when the child has died. This is (currently) only possible thanks to OSProcess primitive. That means OSSubprocess still needs (one or very little) OSProcess primitives down in the VM. When you load either of the projects, they launch the child reaper process, register the semaphore etc etc. So the problem is when you loaded one and you then try to load the second one, the initialization of the second one you plug its own semaphore etc etc and so the previous gets broken as it doesn't have a working child reaper process. If someone has a better idea on how to solve this, then please speak up. Cheers, On Wed, May 23, 2018 at 11:12 AM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Guillermo Polito wrote > > I try not to depend on projects using OSProcess in that case. > > That is not exactly a robust solution! What is the only project providing > the functionality you need depends on OSP?! > > > Guillermo Polito wrote > > I understand that the incompatibilities bother, but putting all the fault > > in OSSubprocess and not in OSProcess seems not fair :) > > Ha ha, well OSProcess was born in 2005, and then OSSP appeared reusing some > of its functionality just recently, so I'd say it's fair indeed! > > > Guillermo Polito wrote > > Maybe both should be modified to be compatible? > > Maybe. I don't really understand the source of the incompatibility well > enough. > > > Guillermo Polito wrote > > I found OSProcess API particularly bad. It's never clear to me whether to > > use OSProcess, PipeableSomething or CommandWhatever (I don't even > remember > > the names of the things that **do work** and I have to look them every > > time). > > The things you're describing are not accidental complexity, but the fact > that OSP (and its companion CommandShell) actually have a far wider feature > set than just simple commands. CommandShell makes many shell-like things > possible in-image, but one doesn't have to use or even know anything about > all that to do simple things. That said, every time I did into CS and see > all the things that are possible I am amazed. > > > Guillermo Polito wrote > > Most people only want to do > > output := OSProcess executeCommand: 'ls'. > > Blocking. Recovering stdout. And that's all. > > (PipeableOSProcess command: 'ls') output > > That doesn't seem horribly complex to do in OSP ;) > > > Guillermo Polito wrote > > Well from a technical point of view, if you want to choose from one or > > another today I'd sayâ¦ > > Ah, interesting and informative. Thank you. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Mariano http://marianopeck.wordpress.com

May 23, 2018

Re: [Pharo-users] [Ann] Some new iceberg videos

by Tim Mackinnon

Guille - the text reads very well, Iâll try and look at the videos later. I just submitted a PR to pharo to try and get the contributions text pointing to the ânewer wayâ so that people donât get off track (like we did earlier this week). (Aside: Its quite nice having these docs in GitHub as does make it easier to propose fixes that people can review and accept/comment on). Presumably those how to contribute docs should then also link to the below, so you also realise how you can help with Iceberg as well? And possibly those videos might also be helpful on the more generic - how to contribute to pharo (in general). By the way - this video - https://www.youtube.com/watch?v=c0IgIT2s6Js&feature=youtu.be <https://www.youtube.com/watch?v=c0IgIT2s6Js&feature=youtu.be> has a very low quality compare to the others. I think maybe a setting was wrong when it was uploaded? Tim > On 23 May 2018, at 17:09, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > This time (just before releasing a new version of iceberg) I wanted to share some videos with you. > Feedback is welcome. > > !! How to contribute to Iceberg > https://youtu.be/yGr5HvVWM0M <https://youtu.be/yGr5HvVWM0M> > > This video shows how to contribute to iceberg. > For this, you should update your iceberg installation and then just do a pull request. > This means that you need to start by forking https://github.com/pharo-vcs/iceberg <https://github.com/pharo-vcs/iceberg> > > - Path 1: Clone and pull (easy) > - Clone your fork > - Checkout the latest development branch (e.g., dev-0.7) > - Pull from pharo-vcs/iceberg > > This path does not always work, as this is kind of self-brain surgery. Iceberg is updating itself. > If this does not work, go to path 2 > > - Path 2: Install from scratch (if Path 1 does not work) > - Use the script in the README file to unload and reinstall iceberg > - Make sure you use the latest development branch in the Metacello script (e.g., dev-0.7) > - Clone your fork and checkout the development branch > > Once you have the correct version, you can load the tests by loading the development group of the baseline. > > > !! Basic Branching and Merging > https://youtu.be/c0IgIT2s6Js <https://youtu.be/c0IgIT2s6Js> > > This video shows in a simple example how to branch, merge and checkout different commits. > In this video we first create a new class with a method, then we create another branch and force a conflict. We resolve the conflict during merge. > > In the middle, bonus feature, we checked out a commit and stayed in Detached HEAD for a while ;) > > !! Loading a baseline from your repository > https://youtu.be/brUHEOr-p_E <https://youtu.be/brUHEOr-p_E> > > This video shows how to load a baseline from Iceberg's UI. > We clone an existing project, see it is "Not loaded" and use Metacello plugin to load the default group. > > Enjoy, > Guille > > PS: Tomorrow I'll answer the threads about Iceberg that were going around here in the mailing list. I was running today.

May 23, 2018

[Ann] Some new iceberg videos

by Guillermo Polito

Hi all, This time (just before releasing a new version of iceberg) I wanted to share some videos with you. Feedback is welcome. !! How to contribute to Iceberg https://youtu.be/yGr5HvVWM0M This video shows how to contribute to iceberg. For this, you should update your iceberg installation and then just do a pull request. This means that you need to start by forking https://github.com/pharo-vcs/iceberg - Path 1: Clone and pull (easy) - Clone your fork - Checkout the latest development branch (e.g., dev-0.7) - Pull from pharo-vcs/iceberg This path does not always work, as this is kind of self-brain surgery. Iceberg is updating itself. If this does not work, go to path 2 - Path 2: Install from scratch (if Path 1 does not work) - Use the script in the README file to unload and reinstall iceberg - Make sure you use the latest development branch in the Metacello script (e.g., dev-0.7) - Clone your fork and checkout the development branch Once you have the correct version, you can load the tests by loading the development group of the baseline. !! Basic Branching and Merging https://youtu.be/c0IgIT2s6Js This video shows in a simple example how to branch, merge and checkout different commits. In this video we first create a new class with a method, then we create another branch and force a conflict. We resolve the conflict during merge. In the middle, bonus feature, we checked out a commit and stayed in Detached HEAD for a while ;) !! Loading a baseline from your repository https://youtu.be/brUHEOr-p_E This video shows how to load a baseline from Iceberg's UI. We clone an existing project, see it is "Not loaded" and use Metacello plugin to load the default group. Enjoy, Guille PS: Tomorrow I'll answer the threads about Iceberg that were going around here in the mailing list. I was running today.

May 23, 2018

Re: [Pharo-users] On UDP broadcast

by N. Bouraqadi

Note that the package includes tests that show that the broadcast working :-) Thanx CÃ©drick for the CC. Noury > On 21 May 2018, at 21:17, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: > > Noury did. He sent that on the other thread : > > Â« Just want to point that I did some work late 2017 on UDP sockets including multicast and broadcast. > The package named 'NetworkExtras' is part of the ReusableBricks repo of my team. > http://smalltalkhub.com/#!/~CAR/ReusableBricks <http://smalltalkhub.com/#!/~CAR/ReusableBricks> > It has some dependencies on other packages. Â» > > It may help. I cc Noury. > > Cheers, > > CÃ©drick > > Le 21 mai 2018 Ã 20:00, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> a Ã©crit : > >> >> >>> On 21 May 2018, at 19:37, Stephan Eggermont <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: >>> >>> Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote:. >>>> >>>> I can't get the broadcast sending via nc to work (like your terminal >>>> example). The -b nc option on macOS is not related to broadcasting. >>> >>> Whoâs allowed to broadcast? >> >> Yes, I vaguely remember that Unix permissions are involved, I just don't know how this works exactly. >> >>> Stephan >>> >>> >> >>

May 23, 2018

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

by David T. Lewis

On Wed, May 23, 2018 at 07:11:29AM -0700, Sean P. DeNigris wrote: > Guillermo Polito wrote > > I try not to depend on projects using OSProcess in that case. > > That is not exactly a robust solution! What is the only project providing > the functionality you need depends on OSP?! > > > Guillermo Polito wrote > > I understand that the incompatibilities bother, but putting all the fault > > in OSSubprocess and not in OSProcess seems not fair :) > > Ha ha, well OSProcess was born in 2005, and then OSSP appeared reusing some > of its functionality just recently, so I'd say it's fair indeed! > Actually, OSProcess was born in 1999 :-) First announcement: http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-June/016553.html And this appears to be where I first starting thinking about the problem: http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-January/025236.… http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-May/023712.html Kudos to Mariano for working closely with me as he developed the FFI based functionality in OSSP, he did a really good job of working out issues wherever possible. FFI based solutions work at a different level of abstraction than VM plugins, and there is a role for both. Dave

May 23, 2018

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

by Steffen MÃ¤rcker

Hi Henry, > [...] it might be possible to try to do this with FFI only? If I understand you correctly, I could use FFI to call an external lib to perform the actual computation according to the rounding mode, right? In this case I'd be worry about the performance impact of many FFI calls. > For the same reason, I hope you intend roundByMethodXWhile: to be a > mandatory API, forgetting to set the mode back when done (or, never > getting > there due to errors, etc) is an area best left unexplored ;) I used roundByMethodXWhile: aBlock just to convey the idea that an API could work "local" and ensures resetting the rounding mode afterwards. =) Best, Steffen

May 23, 2018

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

by Steffen MÃ¤rcker

I'll cross-post there later. Thanks for the suggestion! The application I have in mind is approximation algorithms for systems of linear equations or linear programs. Approximation algorithms, such as the power method, typically run until convergence of the solution vector is reached. However, determining convergence is usually done by computing the difference (epsilon) between the last two solutions and comparing it to some threshold. This may work in some cases but not in general, as the intermediate epsilon does not tell the distance to the actual solution. Interval iteration tackles this problem by approaching the solution from above and below. The difference between the upper and lower solution bounds determines the quality of the solution. However, if we use imprecise arithmetic (floats, doubles) it is important to round down/up in computing the lower/upper bounds. Best, Steffen Am .05.2018, 12:50 Uhr, schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: > On Wed, May 23, 2018 at 11:47 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > >> *bump* >> >> I guess there no way to do this now. But maybe a VM guy can give me how >> difficult it might be to extend the VM accordingly. >> >> > âYes you should followup this question to the VM mailing-list. > Can you open an issue here: > https://github.com/PolyMathOrg/PolyMath/issues > so we don't forget about it ?â > > âDo you have specific needs behind this ?â

May 23, 2018

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

by Sean P. DeNigris

Guillermo Polito wrote > I try not to depend on projects using OSProcess in that case. That is not exactly a robust solution! What is the only project providing the functionality you need depends on OSP?! Guillermo Polito wrote > I understand that the incompatibilities bother, but putting all the fault > in OSSubprocess and not in OSProcess seems not fair :) Ha ha, well OSProcess was born in 2005, and then OSSP appeared reusing some of its functionality just recently, so I'd say it's fair indeed! Guillermo Polito wrote > Maybe both should be modified to be compatible? Maybe. I don't really understand the source of the incompatibility well enough. Guillermo Polito wrote > I found OSProcess API particularly bad. It's never clear to me whether to > use OSProcess, PipeableSomething or CommandWhatever (I don't even remember > the names of the things that **do work** and I have to look them every > time). The things you're describing are not accidental complexity, but the fact that OSP (and its companion CommandShell) actually have a far wider feature set than just simple commands. CommandShell makes many shell-like things possible in-image, but one doesn't have to use or even know anything about all that to do simple things. That said, every time I did into CS and see all the things that are possible I am amazed. Guillermo Polito wrote > Most people only want to do > output := OSProcess executeCommand: 'ls'. > Blocking. Recovering stdout. And that's all. (PipeableOSProcess command: 'ls') output That doesn't seem horribly complex to do in OSP ;) Guillermo Polito wrote > Well from a technical point of view, if you want to choose from one or > another today I'd sayâ¦ Ah, interesting and informative. Thank you. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 23, 2018