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

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

by Esteban A. Maringolo

I agree with you that it is weird, but as I understand it it is because the process of "Saving" a package and "Committing" it is merged into a single action, so there is no way to "save" the package other than committing its changes to the repo. This has the drawback you mentioned, but I guess this enables you to simultaneously save the same package to more than one repository. Maybe a diagram could make the whole picture more clear. Regards, Esteban A. Maringolo 2018-05-22 12:23 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: > Hi - when trying out the new Iceberg with a bunch of developers and explaining the challenges of integrating git and files into a smalltalk realm of the image - there was a lot of interest in how this works. > > When you clone - you obviously see a series of files (in Tonel - nice) that are then brought into your image. If you edit a file like Readme.md (using a markdown editor) you will notice that git status will show you that this file has changed. However if you then edit some methods - and then look in the file system - git status doesnât show these? This in retrospect possibly feels weird - or does it? Iâm not sure anymore - and was wondering if there was a specific reason behind not mirroring code changes back to the file system as they happen? > > When you branch in Pharo, a command line git status does show that change - so some things clearly are being mirrored, just not code (Which Iâm guess happens briefly when you click commit?). > > Iâm curious now to understand the tradeoffs. > > Tim > > p.s. it is very nice for small private projects, to use a git client on your phone - edit a method or two on the train, commit your changes and then see your CI build the results and deploy a new website by the time you get offâ¦ yes its not the rich smalltalk environment for bigger changes - but tiny stuff, its quite nice to fallback on the traditional way. > >

May 22, 2018

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

by Sven Van Caekenberghe

Partial answer, but you saw this, right ? https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary > On 22 May 2018, at 17:23, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi - when trying out the new Iceberg with a bunch of developers and explaining the challenges of integrating git and files into a smalltalk realm of the image - there was a lot of interest in how this works. > > When you clone - you obviously see a series of files (in Tonel - nice) that are then brought into your image. If you edit a file like Readme.md (using a markdown editor) you will notice that git status will show you that this file has changed. However if you then edit some methods - and then look in the file system - git status doesnât show these? This in retrospect possibly feels weird - or does it? Iâm not sure anymore - and was wondering if there was a specific reason behind not mirroring code changes back to the file system as they happen? > > When you branch in Pharo, a command line git status does show that change - so some things clearly are being mirrored, just not code (Which Iâm guess happens briefly when you click commit?). > > Iâm curious now to understand the tradeoffs. > > Tim > > p.s. it is very nice for small private projects, to use a git client on your phone - edit a method or two on the train, commit your changes and then see your CI build the results and deploy a new website by the time you get offâ¦ yes its not the rich smalltalk environment for bigger changes - but tiny stuff, its quite nice to fallback on the traditional way. > >

May 22, 2018

Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

by Tim Mackinnon

Hi - when trying out the new Iceberg with a bunch of developers and explaining the challenges of integrating git and files into a smalltalk realm of the image - there was a lot of interest in how this works. When you clone - you obviously see a series of files (in Tonel - nice) that are then brought into your image. If you edit a file like Readme.md (using a markdown editor) you will notice that git status will show you that this file has changed. However if you then edit some methods - and then look in the file system - git status doesnât show these? This in retrospect possibly feels weird - or does it? Iâm not sure anymore - and was wondering if there was a specific reason behind not mirroring code changes back to the file system as they happen? When you branch in Pharo, a command line git status does show that change - so some things clearly are being mirrored, just not code (Which Iâm guess happens briefly when you click commit?). Iâm curious now to understand the tradeoffs. Tim p.s. it is very nice for small private projects, to use a git client on your phone - edit a method or two on the train, commit your changes and then see your CI build the results and deploy a new website by the time you get offâ¦ yes its not the rich smalltalk environment for bigger changes - but tiny stuff, its quite nice to fallback on the traditional way.

May 22, 2018

Re: [Pharo-users] Pharo 7 - New Iceberg feedback

by Sven Van Caekenberghe

Hi Tim, Thanks for the detailed/constructive feedback. I am sure it will be helpful. Sven > On 22 May 2018, at 17:15, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi - last night we managed to explore the new contribution process as well as the new iceberg ui at the U.K. Smalltalk meetup last night. > > Not many had seen it before so it was a good test run. > > As an initial comment - we need to invest a small amount of time to get the right docs in places you expect them as not doing so undoes a lot of good work - the Pharo main site that points to old contribution docs (and doesnât reference the new ones) must be updated ASAP to keep energy high (we almost lost a few folks last night by going down the wrong path - fortunately Cyril piped up on Discord for me - phew). > > Armed with the right steps it was straightforward - much easier than the older slices mechanism (that I never was comfortable with) - so HUGE thanks for that everyone! > > As we worked through it, the more git seasoned folks were confused why git status in a terminal wasnât really showing the same info as iceberg (Iâll put this in a separate thread to discuss, as itâs an interesting thought which Iâm sure has lively discussion). > > Anyway - the new UI does take some getting used to (personally I liked the compactness of the original Iceberg and its tabs), but when you understand what the different windows show you - I think it makes sense (and hopefully is more stable). We all missed having an obvious Diff mechanism - we later spotted that Commit does show this (Although possibly calling it âCommitâ¦â might make it more obvious that you have a chance to review changes and change your mind) - but knowing the size of your change and reviewing them without any danger of committing something is a useful feature (but maybe a 2.0 enhancement request?). > > One small tweak (which I would PR if I knew how to - would be to swap the status and branch columns in the Repository window to make the status clearer (the status gets lost as it sqashed against the normally much longer branch name). Its a simple change to #initializeRepositoryList but I guess Iceberg is in a different repository (and not in the instructions for contirbutions). > > We also noticed that if you try to use the âCreate Pull Requestâ menu item, you canât if you have 2FA enabled on Github (the recommended setting) as I guess that ssh protocol doesnât allow this with an ssh key? So I we should update the instructions to suggest either using the web ui - or - creating an app specific login (that doesnât use 2fa). - Iâll look at how to add that tweak and send a PR. > > > Tim > > > Sent from my iPhone

May 22, 2018

Pharo 7 - New Iceberg feedback

by Tim Mackinnon

Hi - last night we managed to explore the new contribution process as well as the new iceberg ui at the U.K. Smalltalk meetup last night. Not many had seen it before so it was a good test run. As an initial comment - we need to invest a small amount of time to get the right docs in places you expect them as not doing so undoes a lot of good work - the Pharo main site that points to old contribution docs (and doesnât reference the new ones) must be updated ASAP to keep energy high (we almost lost a few folks last night by going down the wrong path - fortunately Cyril piped up on Discord for me - phew). Armed with the right steps it was straightforward - much easier than the older slices mechanism (that I never was comfortable with) - so HUGE thanks for that everyone! As we worked through it, the more git seasoned folks were confused why git status in a terminal wasnât really showing the same info as iceberg (Iâll put this in a separate thread to discuss, as itâs an interesting thought which Iâm sure has lively discussion). Anyway - the new UI does take some getting used to (personally I liked the compactness of the original Iceberg and its tabs), but when you understand what the different windows show you - I think it makes sense (and hopefully is more stable). We all missed having an obvious Diff mechanism - we later spotted that Commit does show this (Although possibly calling it âCommitâ¦â might make it more obvious that you have a chance to review changes and change your mind) - but knowing the size of your change and reviewing them without any danger of committing something is a useful feature (but maybe a 2.0 enhancement request?). One small tweak (which I would PR if I knew how to - would be to swap the status and branch columns in the Repository window to make the status clearer (the status gets lost as it sqashed against the normally much longer branch name). Its a simple change to #initializeRepositoryList but I guess Iceberg is in a different repository (and not in the instructions for contirbutions). We also noticed that if you try to use the âCreate Pull Requestâ menu item, you canât if you have 2FA enabled on Github (the recommended setting) as I guess that ssh protocol doesnât allow this with an ssh key? So I we should update the instructions to suggest either using the web ui - or - creating an app specific login (that doesnât use 2fa). - Iâll look at how to add that tweak and send a PR. Tim Sent from my iPhone

May 22, 2018

Re: [Pharo-users] [TechTalk] TODAY, 17h: Pillar

by Marcus Denker

> On 17 May 2018, at 15:44, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > Today, 17h europe time. > > Pharo TechTalk: Pillar > https://association.pharo.org/event-2797069 > > Sorry for the late announcement (we did not know if we could make it today) > The recording is available here: https://www.youtube.com/watch?v=cdi3Vz3oaAs <https://www.youtube.com/watch?v=cdi3Vz3oaAs> I have updated the archive: https://pharo.org/TechTalk <https://pharo.org/TechTalk> We are looking for someone who wants to take over the June TechTalk! Marcus

May 22, 2018

Re: [Pharo-users] On UDP broadcast

by Henrik Sperre Johansen

HilaireFernandes wrote > Thanks Sven for the indications. > > Of course I already looked at this Test, but I got lost. I looked at it > again, and wrote something like: > > | socket data | socket := Socket newUDP. socket setPort: 9999. > socket waitForConnectionFor: 2; waitForDataFor: 5 . data := Array > new: 100. Â Â Â [socket receiveUDPDataInto: data. Â Â Â data crLog] > ensure: [ 'Closing socket' crLog. socket closeAndDestroy] > > I do not have error, but a time out. > > Dr. Geo > http://drgeo.eu With UDP, there is no connection concept, so I'd reckon waitForConnectionFor: is what gives you a TimeOut error... Delete that, only use waitForDataFor: n , put it in a loop (so it won't stop listening until it receives a request), and you should be fine. Doesn't quite look like neither server nor client yet, the workflow should be something like: 1) server (you) starts, listening to port you're using and waitsForData: in an infinite loop. 2) client (student) starts, sends request to broadcast address/port, then waitsForData: on the socket it created. 3) broadcast server reads request, generates reply, and sends it to the originIP/port of the request 4) client receives reply, handles it, and closes socket. Cheers, Henry PS. Why use nc when you already have a working broadcast client in pharo? ;) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

May 22, 2018

Re: [Pharo-users] [Pharo-dev] LibFFI/NB Cairo External Module Not Found debugging

by Esteban Lorenzano

why libcairo2-dev and not just libcairo2? cheers, Esteban > On 21 May 2018, at 17:25, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > Thank you for that. The instructions there are incomplete. > It is necessary to add > sudo apt-get install libcairo2-dev:i386 > to the script. > > On 21 May 2018 at 19:36, John Pfersich <jpfersich(a)gmail.com <mailto:jpfersich@gmail.com>> wrote: > If you are running a 32 bit Pharo on a 64 bit Ubuntu, there is instructions for additional steps needed at https://pharo.org/gnu-linux-installation <https://pharo.org/gnu-linux-installation> under the âPrepare 64-bit-Linux for 32bit Pharoâ heading > > For encrypted mail use jgpfersich(a)protonmail.com <mailto:jgpfersich@protonmail.com> > Get a free account at ProtonMail.com <http://protonmail.com/> > Web: www.objectnets.net <http://www.objectnets.net/> and www.objectnets.org <http://www.objectnets.org/> > > On May 21, 2018, at 00:18, Richard O'Keefe <raoknz(a)gmail.com <mailto:raoknz@gmail.com>> wrote: > >> It's not just Windows users. I have Pharo 6.0 #605.40 >> running under Linux Ubuntu version 17.10 and the cairo >> library is definitely installed. >> >> Just starting Pharo is a little concerning: >> ok@Herbrand:~/Smalltalk$ pharo >> ioLoadModule(/home/ok/Pharo.d/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so): >> libfreetype.so.6: cannot open shared object file: No such file or directory >> ioLoadModule(/home/ok/Pharo.d/pharo-vm/lib/pharo/5.0-201707201942/FT2Plugin.so): >> libfreetype.so.6: cannot open shared object file: No such file or directory >> Yet these files exist. >> /usr/lib/x86_64-linux-gnu/libfreetype.a >> /usr/lib/x86_64-linux-gnu/libfreetype.so >> /usr/lib/x86_64-linux-gnu/libfreetype.la <http://libfreetype.la/> >> /usr/lib/x86_64-linux-gnu/libfreetype.so.6 >> /usr/lib/x86_64-linux-gnu/libfreetype.so.6.14.0 >> >> When I try any Roassal examples, I get >> Error: cannot locate cairo library. Please check if it is installed ... >> CairoLibrary(Object) error: >> CairoLibrary unix32ModuleName >> Unix32Platform ffiModuleName >> CairoLibrayr(FFILibrary) moduleName >> FFICalloutMethodBuilder moduleName >> >> The 32 is the clue. Apparently I'm running a 32-bit Pharo >> with 64-bit libraries installed. Could this be the problem >> on Windows? >> >> >> On 21 May 2018 at 07:46, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> >> On Sat, May 19, 2018 at 1:37 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >> Hi, >> >> some Windows users are repeatedly running into Pharo failing to load Cairo library on Windows (see stack screenshot at the bottom). >> >> The problem is that I have no idea how to even start debugging this. >> >> Is there some documentation on how Pharo loads libraries via FFI on Windows that I can start digging into? >> >> Note that the library is definitely present, as this happens only occasionally -- it can be fixed by restarting PC. But I cannot reasonably ask users to restart just because Pharo decided it doesn't feel like loading a library. >> >> Any pointers / docs / ideas appreciated. >> >> You can see the actual code from >> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93&q=f… <https://github.com/OpenSmalltalk/opensmalltalk-vm/search?utf8=%E2%9C%93&q=f…> >> >> ? >> >> >> Thanks, >> Peter >> >> <image.png> >> >> >> >> >> -- >> >> Guille Polito >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> CRIStAL - UMR 9189 >> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >> >> Web: http://guillep.github.io <http://guillep.github.io/> >> Phone: +33 06 52 70 66 13 >> >

May 22, 2018

Re: [Pharo-users] On UDP broadcast

by CÃ©drick BÃ©ler

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 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> a Ã©crit : > > > >> On 21 May 2018, at 19:37, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> Sven Van Caekenberghe <sven(a)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 21, 2018

Re: [Pharo-users] On UDP broadcast

by Sven Van Caekenberghe

> On 21 May 2018, at 19:37, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Sven Van Caekenberghe <sven(a)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 21, 2018