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

Reverting changes in Iceberg

by Evan Donahue

Hi, I was trying to merge changes from a collaborator from github into my local image and, through some flurry of menus I didn't quite comprehend, it seems to have blown away their changes and left me a commit ahead with all of their changes deleted. How can I revert back to their change, which I do see in my history, and continue from there without my erroneous most recent commit? Thanks, Evan

May 24, 2018

Re: [Pharo-users] im using pharo in wayland system.

by Thierry Goubier

Le 24/05/2018 Ã 18:16, peter yoo a Ã©critÂ : > thank you. Thierry :D Ok, I checked again, now that I'm back with a 18.04 system. I have SourceCodePro and SourceSansPro as fonts. Thierry

May 24, 2018

Re: [Pharo-users] Handling socket timed out

by Sven Van Caekenberghe

> On 24 May 2018, at 19:28, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi, > > With this code, the ConnectionTimedOut exception is never handled: > > | socket data | > socket := Socket newUDP. > socket setPort: 51284. > socket waitForDataFor: 5. > data := ByteArray new: 100. > [[socket receiveUDPDataInto: data] > on: Error > do: ['Catched error, closing socket' crLog. socket closeAndDestroy]] > ensure: [ 'Closing socket' crLog. socket closeAndDestroy] > > Any reason it does not work? > > In Pharo I see several examples using ifCurtailed. > > Hilaire > > -- > Dr. Geo > http://drgeo.eu #receiveUDPDataInto: returns immediately, possibly with zero bytes read. It is #waitForDataFor: that signals the ConnectionTimedOut. Move that expression into the inner block. Sven

May 24, 2018

Handling socket timed out

by Hilaire

Hi, With this code, the ConnectionTimedOut exception is never handled: | socket data | socket := Socket newUDP. socket setPort: 51284. socket waitForDataFor: 5. data := ByteArray new: 100. [[socket receiveUDPDataInto: data] Â Â Â on: Error Â Â Â do: ['Catched error, closing socket' crLog. socket closeAndDestroy]] Â Â Â ensure: [ 'Closing socket' crLog. socket closeAndDestroy] Any reason it does not work? In Pharo I see several examples using ifCurtailed. Hilaire -- Dr. Geo http://drgeo.eu

May 24, 2018

Re: [Pharo-users] im using pharo in wayland system.

by peter yoo

thank you. Thierry :D

May 24, 2018

Re: [Pharo-users] im using pharo in wayland system.

by Thierry Goubier

Le jeu. 24 mai 2018 16:23, peter yoo <onionmixer(a)gmail.com> a Ã©crit : > to Guillermo > where can download pharo 7? cannot find from google. > > to Thierry > hm... same now... install font and fc-cache later is same. > and.... im using nouveau driver. using wayland now :D > Oh, ok, maybe it's a nouveau driver constraint. I installed two fonts. I need to check again. Thierry >

May 24, 2018

Re: [Pharo-users] im using pharo in wayland system.

by peter yoo

to Guillermo > where can download pharo 7? cannot find from google. to Thierry > hm... same now... install font and fc-cache later is same. and.... im using nouveau driver. using wayland now :D

May 24, 2018

Re: [Pharo-users] How to LAN feature

by Hilaire

Yes, it is only to know where is the server, then I will use your Zinc framework for the real exchange stuff. The udp message may just be 'DrGeoShare' Le 24/05/2018 Ã 15:51, Sven Van Caekenberghe a Ã©critÂ : > Yes, each UDP packet always contains both the sender and receiver IP (and port). > But remember UDP is asynchronous and unreliable, as well as limited in payload size. -- Dr. Geo http://drgeo.eu

May 24, 2018

Re: [Pharo-users] im using pharo in wayland system.

by Thierry Goubier

Hi Peter, I've seen the same error on a fresh 18.04 system I have installed last week, and the solution was to add the Open Sans fonts to the user folder (~/.fonts) and rebuild X font cache. By the way, Ubuntu 17.10 was Wayland, Ubuntu 18.04 is not Wayland, as far as I know. And I had Pharo working on both. Regards, Thierry 2018-05-24 14:06 GMT+02:00 peter yoo <onionmixer(a)gmail.com>: > hello! im new install ubuntu 18.04 LTS to my desktop. but pharo cannot run. > > look a attached png then know the problem. cannot using wirh wayland system > now? > > maybe guess.... because freetype.... have a solution then help to me please. > > -- > http://lookandwalk.com http://looknw.com | http://onionmixer.net > peter yoo(Jonghwa Yoo). ROK

May 24, 2018

Re: [Pharo-users] How to LAN feature

by Sven Van Caekenberghe

Yes, each UDP packet always contains both the sender and receiver IP (and port). But remember UDP is asynchronous and unreliable, as well as limited in payload size. > On 24 May 2018, at 15:48, Hilaire <hilaire(a)drgeo.eu> wrote: > > Oh, for the record, regarding the issue discussed bellow about determining the NIC IP. > > When a server broadcast an UDP message, the client receiving it can fetch the server NIC IP from the result returned by the #receiveUDPDataInto: message. > > I only tested it on the same workstation, but I guess it work as the UDP datagram is encapsulated in an IP packet. > > Hilaire > > Le 14/05/2018 Ã 11:28, Henrik Sperre Johansen a Ã©crit : >> That's the "old" ipv4 primitive. >> The "new" ipv4/ipv6 primitive >> (sqResolverGetAddressInfoHostSizeServiceSizeFlagsFamilyTypeProtocol) uses >> getaddrinfo instead, and lets you interate over the results; this is what >> the SSDP package tries to do when you specify allLocalV4Addresses. >> >> It's unreliable because: >> 1) Finding the correct hostname can be difficult (iirc, some vm's fail the >> hostname prim, and always returns the fallback 'localhost') >> 2) It uses DNS lookups, which can both be slow, and depend on network >> configuration. >> 3) The correct domain to use when you want aggregated results over multiple >> interfaces (.local? nothing?) differs from platform to platform. (iirc, OSX >> only ever returns a single entry if adding .local) >> >> "However when I activate a second network interface, this last one returns >> an empty collection" >> I just tested on a Windows 10 machine with 6.1 release (Pharo 6.1 >> stable\Pharo.exe >> CoInterpreter VMMaker.oscog-eem.2254 uuid: >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017), for me the statement >> part := SSDPParticipant new. >> part allLocalV4Addresses. >> correctly returns 1/2/1 addresses when connecting/disconnecting to a >> wireless network :/ >> >> Why lookup would start to fail when you activate an interface, and stay >> failing after you remove it, I couldn't say, but I can say that >> SSDPParticipant >> hostName returning names that DNS won't resolve properly >> for some or another reason has been a problem I've encountered before. > > -- > Dr. Geo > http://drgeo.eu > > >

May 24, 2018

Re: [Pharo-users] How to LAN feature

by Hilaire

Oh, for the record, regarding the issue discussed bellow about determining the NIC IP. When a server broadcast an UDP message, the client receiving it can fetch the server NIC IP from the result returned by the #receiveUDPDataInto: message. I only tested it on the same workstation, but I guess it work as the UDP datagram is encapsulated in an IP packet. Hilaire Le 14/05/2018 Ã 11:28, Henrik Sperre Johansen a Ã©critÂ : > That's the "old" ipv4 primitive. > The "new" ipv4/ipv6 primitive > (sqResolverGetAddressInfoHostSizeServiceSizeFlagsFamilyTypeProtocol) uses > getaddrinfo instead, and lets you interate over the results; this is what > the SSDP package tries to do when you specify allLocalV4Addresses. > > It's unreliable because: > 1) Finding the correct hostname can be difficult (iirc, some vm's fail the > hostname prim, and always returns the fallback 'localhost') > 2) It uses DNS lookups, which can both be slow, and depend on network > configuration. > 3) The correct domain to use when you want aggregated results over multiple > interfaces (.local? nothing?) differs from platform to platform. (iirc, OSX > only ever returns a single entry if adding .local) > > "However when I activate a second network interface, this last one returns > an empty collection" > I just tested on a Windows 10 machine with 6.1 release (Pharo 6.1 > stable\Pharo.exe > CoInterpreter VMMaker.oscog-eem.2254 uuid: > 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017), for me the statement > part := SSDPParticipant new. > part allLocalV4Addresses. > correctly returns 1/2/1 addresses when connecting/disconnecting to a > wireless network :/ > > Why lookup would start to fail when you activate an interface, and stay > failing after you remove it, I couldn't say, but I can say that > SSDPParticipant >> hostName returning names that DNS won't resolve properly > for some or another reason has been a problem I've encountered before. -- Dr. Geo http://drgeo.eu

May 24, 2018

Re: [Pharo-users] im using pharo in wayland system.

by Guillermo Polito

Hi Peter, would you mind testing latest Pharo7 also and telling us if you see some similar problem? Several things were improved in the freetype bindings since Pharo6, and probably this is fixed?. Tx, Guille On Thu, May 24, 2018 at 2:06 PM, peter yoo <onionmixer(a)gmail.com> wrote: > hello! im new install ubuntu 18.04 LTS to my desktop. but pharo cannot run. > > look a attached png then know the problem. cannot using wirh wayland > system now? > > maybe guess.... because freetype.... have a solution then help to me > please. > > -- > http://lookandwalk.com http://looknw.com | http://onionmixer.net > peter yoo(Jonghwa Yoo). ROK > -- 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 24, 2018

im using pharo in wayland system.

by peter yoo

hello! im new install ubuntu 18.04 LTS to my desktop. but pharo cannot run. look a attached png then know the problem. cannot using wirh wayland system now? maybe guess.... because freetype.... have a solution then help to me please. -- http://lookandwalk.com http://looknw.com | http://onionmixer.net peter yoo(Jonghwa Yoo). ROK

May 24, 2018

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

by Steffen MÃ¤rcker

Hi, now I've observed the same issue. It might be related to context switching, since introducing a delay has a similar effect. Consider: | FE_TONEAREST FE_DOWNWARD FE_UPWARD FE_TOWARDZERO | FE_TONEAREST := 16r0000. FE_DOWNWARD := 16r0400. FE_UPWARD := 16r0800. FE_TOWARDZERO := 16r0C00. "For some reasons we have to call fegetround once." "c := LibC new fegetround." LibC new fesetround: FE_DOWNWARD. (Delay forSeconds: 1) wait. v1 := 1.0/10.0. LibC new fesetround: FE_UPWARD. v2 := 1.0/10.0. LibC new fesetround: FE_TONEAREST. v1 < v2. If the delay is inserted, the script evaluates to false. Using the same LibC-instance or creating a new one does not seem to change anything here. Interestingly, a similar approach in VisualWorks does not show this issue yet. Actually, I expect the FE_* macros to be platform/implementation dependent, as suggested here: http://www.enseignement.polytechnique.fr/informatique/INF478/docs/Cpp/en/c/… Best, Steffen Am .05.2018, 11:57 Uhr, schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>: > What is really strange is when I print the following lines, I obtain > 2048: > > current := LibC uniqueInstance fegetround. > LibC uniqueInstance fesetround: 2048. > LibC uniqueInstance fegetround. > > and 0 when I remove the first line : > LibC uniqueInstance fesetround: 2048. > LibC uniqueInstance fegetround. > > > > On Thu, May 24, 2018 at 10:37 AM Serge Stinckwich < > serge.stinckwich(a)gmail.com> wrote: > >> >> >> On Thu, May 24, 2018 at 10:31 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: >> >>> I actually made progress: It works like a charm! Basically, I >>> implemented >>> the same code as you. Testing is straightforward (using the constant >>> values from libc): >>> >>> current := LibC fegetround. >>> LibC fesetround: FE_DOWNWARDS. >>> v1 := 1.0/10.0. >>> LibC feesetround: FE_UPWARDS. >>> v2 := 1.0/10.0. >>> LibC feesetround: current. >>> v1 < v2. "true" >>> >>> > âbut apparently nothing happens when you do : >>> > LibC uniqueInstance fesetround: 1024. >>> > LibC uniqueInstance fegetround. >>> > always return 0.â >>> >>> This is expected, since the fesetround function returns 0 only if the >>> set >>> operation was successful. >>> >>> >> âI was talking about fgetround function. >> â Can you check the value returns by your fegetround function ?â >> >> Constants values are not dependent of the platform ?â >> >> âCan you commit yr code to Pharo 7.0 or if there is no interest for this >> to PolyMath ?â >> âThank you.â >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (SU/IRD/UY1) >> "Programs must be written for people to read, and only incidentally for >> machines to execute."http://www.doesnotunderstand.org/ >> >

May 24, 2018

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

by Serge Stinckwich

What is really strange is when I print the following lines, I obtain 2048: current := LibC uniqueInstance fegetround. LibC uniqueInstance fesetround: 2048. LibC uniqueInstance fegetround. and 0 when I remove the first line : LibC uniqueInstance fesetround: 2048. LibC uniqueInstance fegetround. On Thu, May 24, 2018 at 10:37 AM Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > > > On Thu, May 24, 2018 at 10:31 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > >> I actually made progress: It works like a charm! Basically, I >> implemented >> the same code as you. Testing is straightforward (using the constant >> values from libc): >> >> current := LibC fegetround. >> LibC fesetround: FE_DOWNWARDS. >> v1 := 1.0/10.0. >> LibC feesetround: FE_UPWARDS. >> v2 := 1.0/10.0. >> LibC feesetround: current. >> v1 < v2. "true" >> >> > âbut apparently nothing happens when you do : >> > LibC uniqueInstance fesetround: 1024. >> > LibC uniqueInstance fegetround. >> > always return 0.â >> >> This is expected, since the fesetround function returns 0 only if the >> set >> operation was successful. >> >> > âI was talking about fgetround function. > â Can you check the value returns by your fegetround function ?â > > Constants values are not dependent of the platform ?â > > âCan you commit yr code to Pharo 7.0 or if there is no interest for this > to PolyMath ?â > âThank you.â > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for > machines to execute."http://www.doesnotunderstand.org/ > -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

May 24, 2018

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

by Guillermo Polito

Aaand, I've updated https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo On Thu, May 24, 2018 at 11:34 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > https://github.com/pharo-vcs/iceberg/wiki/The-Working-Copy(ies) > https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging > > On Thu, May 24, 2018 at 11:30 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi, >> >> I'll take some minutes to provide an answer as detailed as possible to >> all questions in this mail, and to the ones in the mails before. >> But first, since I know most people only read the first lines of mails >> :P, if you find any concrete iceberg issues, please report them in >> >> https://github.com/pharo-vcs/iceberg/issues >> >> Now, answers inline. >> >> On Tue, May 22, 2018 at 5:15 PM, 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. >>> >> >> Cool! >> >> >>> >>> 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). >>> >> >> I know. This is indeed important. I'm trying to get time to make videos, >> paste as much info in the wiki. Now, it would be good to know what was >> exactly your "wrong path". The more concrete you are, the easier is to fix >> it :). >> I see Pharo contribution page (http://pharo.org/contribute-propose-fix) >> points to https://github.com/pharo-project/pharo/wiki/Contribute-a- >> fix-to-Pharo which is outdated. I'll fix it ASAP. >> >> >>> >>> 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). >>> >> >> Well, this is the discussion in the other thread. If you have read the >> glosssary (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary) >> you will notice that iceberg presents you with two working copies: >> - the image working copy >> - the disk working copy >> >> The disk working copy is what most people know when they use git. The >> directory where you have your repository, with the files you're modifying. >> >> The image working copy represent what is loaded in Pharo. It's important >> to differentiate them because if I send you an image (or you download it >> from somewhere) you have code loaded on it. This working copy allows us to >> track how and where you loaded that code from. That is useful if later on >> you want to contribute to that project in some way. >> >> Then there are other questions: >> >> !! Why do we still have a disk working copy? >> >> Well, this is not really necessary for iceberg to work. Iceberg could >> just write source code directly on git's BLOB, as Thierry mentioned in the >> other thread. >> The reason for this working copy to be there is just to try to be less >> alien. >> Having the disk working copy allows people to still have a way to: >> - edit non-smalltalk files from the command like >> - use the non command line as a last ressource if something goes wrong >> with your Pharo image >> - use external tools to manage the repository (sourcetree, git kraken, >> whatever you're confortable with) >> >> The idea is that Iceberg will try to keep your disk working copy in sync >> with your repository HEAD. >> It will take care of transparently synchronizing your disk working copy >> when: >> - you commit >> - you change branches >> - you pull/push/merge >> >> !! Why don't we dump code into the disk as we write it? >> >> The main reason behind it is that the image is not causally connected to >> the directory in disk, as Ben implied. >> There is not a 1 to 1 correspondence between what you could ever have in >> disk and your running image. >> As Ben mentionned, for this to happen: >> - changing the source code in disk should get automatically loaded into >> Pharo >> - changing the source code in Pharo should get automatically written in >> disk >> >> The thing is that this is much more difficult than it sounds: >> - What happens if you do not want to save your image, you forgot to save >> it or it crashes? Suddenly you will have an image that is not in sync with >> your repository. Would you load all changes into your image as soon as you >> reopen it? Atomically? >> - What happens if you share your repository between several images? >> - Or if suddenly you change your branch from the command line to >> something completely different? >> >> Several of these usecases don't even make sense. So we preferred to >> choose the path of "make it explicit". >> Of course, we could do better, we are open to discuss any improvements. >> Just take into account that Iceberg did not come from an egg :) we have >> thought about many possible scenarios and discussed with a lot of people >> before. >> >> !! How does merge work? >> >> First, just for the record, merge works. We even >> - detect fast forward merge avoiding the creation of extra merge commits >> - proposing a single UI to resolve all conflicts of a project at once >> and not one per package >> >> Now, as Thierry suggested in the other thread, Iceberg's merge happen in >> memory. The reason behind this is that using Git's default merge mechanism >> would insert the >>>> <<<< markers in the conflicting files. This would >> break our parsers and all our tools. >> Instead, we ask git for the list of conflicting files, and we build a >> diff tree in memory, that we later augment with information such as >> conflicts. >> >> There are some issues we have seen when merging external files, but as >> soon as the two merged commits are not merging external files, but we hope >> we will fix them soon. >> >> Missing feature: right now we can only choose between incoming or loaded >> version during a merge. It would be nice to be able to edit a method's >> code, picking part of the incoming code and part of the current code. >> >> Missing feature 2: right now we resolve all conflicts in memory and >> commit them at once. We know some people would like to, instead, not do the >> merge automatically, so they can test it before committing. This should not >> be tooo difficult to do but it was down in the priority list :). >> >> !! Exporting without commiting? >> >> There is no UI support for this, but it is doable from the backend, >> though not correctly exposed right now. >> >> You can right-click on the repository -> Extras -> Inspect >> >> repository index updateDiskWorkingCopy: repository workingCopy >> workingCopyDiff. >> >> >>> 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). >> >> >> Well, the UI rewriting has several ideas behind. I'll put whichever ones >> come to my mind in here, I hope Esteban will correct me if I'm wrong: >> >> - Moving from Glamour to Spec. This is a purely technical decision. >> AFAIK, maybe I'm wrong, Glamour is not being maintained anymore by the GT >> team, and it has some rough corners that made the old UI difficult to deal >> with sometimes. From an investment of time standpoint, we decided to put >> effort in Spec instead... >> - Simplify the UI. We needed it to be less overwhelming and sometimes >> more direct. That's the why of the toolbar on the top, and the more (but >> smaller and simpler) windows. >> >> Regarding the design, Esteban followed some UI guidelines for the design >> taken from I don't where. But at the end we are engineers, not UI >> designers, so we make ugly UIs by default :P. >> Any improvement or concrete suggestion on this direction is welcome :). >> >> >>> 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?). >>> >> >> Yes, I want that also. I miss >> - a Diff/See Changes button. >> - that the tabs that show the diffs should maybe say "Diff: XXX to YYY" >> instead of just "XXX to YYY" >> >> Could you open an issue? >> >> >>> >>> 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). >>> >> >> Could you open an issue? >> >> >>> >>> 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. >>> >> >> Ouki :) >> >> Thanks! >> >> >>> >>> >>> Tim >>> >>> >>> Sent from my iPhone >>> >> >> >> >> -- >> >> >> >> 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 >> > > > > -- > > > > 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 > -- 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 24, 2018

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

by Serge Stinckwich

On Thu, May 24, 2018 at 10:31 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > I actually made progress: It works like a charm! Basically, I implemented > the same code as you. Testing is straightforward (using the constant > values from libc): > > current := LibC fegetround. > LibC fesetround: FE_DOWNWARDS. > v1 := 1.0/10.0. > LibC feesetround: FE_UPWARDS. > v2 := 1.0/10.0. > LibC feesetround: current. > v1 < v2. "true" > > > âbut apparently nothing happens when you do : > > LibC uniqueInstance fesetround: 1024. > > LibC uniqueInstance fegetround. > > always return 0.â > > This is expected, since the fesetround function returns 0 only if the set > operation was successful. > > âI was talking about fgetround function. â Can you check the value returns by your fegetround function ?â Constants values are not dependent of the platform ?â âCan you commit yr code to Pharo 7.0 or if there is no interest for this to PolyMath ?â âThank you.â -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

May 24, 2018

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

by Guillermo Polito

https://github.com/pharo-vcs/iceberg/wiki/The-Working-Copy(ies) https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging On Thu, May 24, 2018 at 11:30 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi, > > I'll take some minutes to provide an answer as detailed as possible to all > questions in this mail, and to the ones in the mails before. > But first, since I know most people only read the first lines of mails :P, > if you find any concrete iceberg issues, please report them in > > https://github.com/pharo-vcs/iceberg/issues > > Now, answers inline. > > On Tue, May 22, 2018 at 5:15 PM, 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. >> > > Cool! > > >> >> 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). >> > > I know. This is indeed important. I'm trying to get time to make videos, > paste as much info in the wiki. Now, it would be good to know what was > exactly your "wrong path". The more concrete you are, the easier is to fix > it :). > I see Pharo contribution page (http://pharo.org/contribute-propose-fix) > points to https://github.com/pharo-project/pharo/wiki/Contribute- > a-fix-to-Pharo which is outdated. I'll fix it ASAP. > > >> >> 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). >> > > Well, this is the discussion in the other thread. If you have read the > glosssary (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary) > you will notice that iceberg presents you with two working copies: > - the image working copy > - the disk working copy > > The disk working copy is what most people know when they use git. The > directory where you have your repository, with the files you're modifying. > > The image working copy represent what is loaded in Pharo. It's important > to differentiate them because if I send you an image (or you download it > from somewhere) you have code loaded on it. This working copy allows us to > track how and where you loaded that code from. That is useful if later on > you want to contribute to that project in some way. > > Then there are other questions: > > !! Why do we still have a disk working copy? > > Well, this is not really necessary for iceberg to work. Iceberg could just > write source code directly on git's BLOB, as Thierry mentioned in the other > thread. > The reason for this working copy to be there is just to try to be less > alien. > Having the disk working copy allows people to still have a way to: > - edit non-smalltalk files from the command like > - use the non command line as a last ressource if something goes wrong > with your Pharo image > - use external tools to manage the repository (sourcetree, git kraken, > whatever you're confortable with) > > The idea is that Iceberg will try to keep your disk working copy in sync > with your repository HEAD. > It will take care of transparently synchronizing your disk working copy > when: > - you commit > - you change branches > - you pull/push/merge > > !! Why don't we dump code into the disk as we write it? > > The main reason behind it is that the image is not causally connected to > the directory in disk, as Ben implied. > There is not a 1 to 1 correspondence between what you could ever have in > disk and your running image. > As Ben mentionned, for this to happen: > - changing the source code in disk should get automatically loaded into > Pharo > - changing the source code in Pharo should get automatically written in > disk > > The thing is that this is much more difficult than it sounds: > - What happens if you do not want to save your image, you forgot to save > it or it crashes? Suddenly you will have an image that is not in sync with > your repository. Would you load all changes into your image as soon as you > reopen it? Atomically? > - What happens if you share your repository between several images? > - Or if suddenly you change your branch from the command line to > something completely different? > > Several of these usecases don't even make sense. So we preferred to choose > the path of "make it explicit". > Of course, we could do better, we are open to discuss any improvements. > Just take into account that Iceberg did not come from an egg :) we have > thought about many possible scenarios and discussed with a lot of people > before. > > !! How does merge work? > > First, just for the record, merge works. We even > - detect fast forward merge avoiding the creation of extra merge commits > - proposing a single UI to resolve all conflicts of a project at once and > not one per package > > Now, as Thierry suggested in the other thread, Iceberg's merge happen in > memory. The reason behind this is that using Git's default merge mechanism > would insert the >>>> <<<< markers in the conflicting files. This would > break our parsers and all our tools. > Instead, we ask git for the list of conflicting files, and we build a diff > tree in memory, that we later augment with information such as conflicts. > > There are some issues we have seen when merging external files, but as > soon as the two merged commits are not merging external files, but we hope > we will fix them soon. > > Missing feature: right now we can only choose between incoming or loaded > version during a merge. It would be nice to be able to edit a method's > code, picking part of the incoming code and part of the current code. > > Missing feature 2: right now we resolve all conflicts in memory and commit > them at once. We know some people would like to, instead, not do the merge > automatically, so they can test it before committing. This should not be > tooo difficult to do but it was down in the priority list :). > > !! Exporting without commiting? > > There is no UI support for this, but it is doable from the backend, though > not correctly exposed right now. > > You can right-click on the repository -> Extras -> Inspect > > repository index updateDiskWorkingCopy: repository workingCopy > workingCopyDiff. > > >> 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). > > > Well, the UI rewriting has several ideas behind. I'll put whichever ones > come to my mind in here, I hope Esteban will correct me if I'm wrong: > > - Moving from Glamour to Spec. This is a purely technical decision. > AFAIK, maybe I'm wrong, Glamour is not being maintained anymore by the GT > team, and it has some rough corners that made the old UI difficult to deal > with sometimes. From an investment of time standpoint, we decided to put > effort in Spec instead... > - Simplify the UI. We needed it to be less overwhelming and sometimes > more direct. That's the why of the toolbar on the top, and the more (but > smaller and simpler) windows. > > Regarding the design, Esteban followed some UI guidelines for the design > taken from I don't where. But at the end we are engineers, not UI > designers, so we make ugly UIs by default :P. > Any improvement or concrete suggestion on this direction is welcome :). > > >> 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?). >> > > Yes, I want that also. I miss > - a Diff/See Changes button. > - that the tabs that show the diffs should maybe say "Diff: XXX to YYY" > instead of just "XXX to YYY" > > Could you open an issue? > > >> >> 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). >> > > Could you open an issue? > > >> >> 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. >> > > Ouki :) > > Thanks! > > >> >> >> Tim >> >> >> Sent from my iPhone >> > > > > -- > > > > 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 > -- 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 24, 2018

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

by Steffen MÃ¤rcker

I actually made progress: It works like a charm! Basically, I implemented the same code as you. Testing is straightforward (using the constant values from libc): current := LibC fegetround. LibC fesetround: FE_DOWNWARDS. v1 := 1.0/10.0. LibC feesetround: FE_UPWARDS. v2 := 1.0/10.0. LibC feesetround: current. v1 < v2. "true" > âbut apparently nothing happens when you do : > LibC uniqueInstance fesetround: 1024. > LibC uniqueInstance fegetround. > always return 0.â This is expected, since the fesetround function returns 0 only if the set operation was successful. Thanks again for your support! Best, Steffen

May 24, 2018

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

by Guillermo Polito

Hi, I'll take some minutes to provide an answer as detailed as possible to all questions in this mail, and to the ones in the mails before. But first, since I know most people only read the first lines of mails :P, if you find any concrete iceberg issues, please report them in https://github.com/pharo-vcs/iceberg/issues Now, answers inline. On Tue, May 22, 2018 at 5:15 PM, 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. > Cool! > > 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). > I know. This is indeed important. I'm trying to get time to make videos, paste as much info in the wiki. Now, it would be good to know what was exactly your "wrong path". The more concrete you are, the easier is to fix it :). I see Pharo contribution page (http://pharo.org/contribute-propose-fix) points to https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo which is outdated. I'll fix it ASAP. > > 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). > Well, this is the discussion in the other thread. If you have read the glosssary (https://github.com/pharo-vcs/iceberg/wiki/Iceberg-glossary) you will notice that iceberg presents you with two working copies: - the image working copy - the disk working copy The disk working copy is what most people know when they use git. The directory where you have your repository, with the files you're modifying. The image working copy represent what is loaded in Pharo. It's important to differentiate them because if I send you an image (or you download it from somewhere) you have code loaded on it. This working copy allows us to track how and where you loaded that code from. That is useful if later on you want to contribute to that project in some way. Then there are other questions: !! Why do we still have a disk working copy? Well, this is not really necessary for iceberg to work. Iceberg could just write source code directly on git's BLOB, as Thierry mentioned in the other thread. The reason for this working copy to be there is just to try to be less alien. Having the disk working copy allows people to still have a way to: - edit non-smalltalk files from the command like - use the non command line as a last ressource if something goes wrong with your Pharo image - use external tools to manage the repository (sourcetree, git kraken, whatever you're confortable with) The idea is that Iceberg will try to keep your disk working copy in sync with your repository HEAD. It will take care of transparently synchronizing your disk working copy when: - you commit - you change branches - you pull/push/merge !! Why don't we dump code into the disk as we write it? The main reason behind it is that the image is not causally connected to the directory in disk, as Ben implied. There is not a 1 to 1 correspondence between what you could ever have in disk and your running image. As Ben mentionned, for this to happen: - changing the source code in disk should get automatically loaded into Pharo - changing the source code in Pharo should get automatically written in disk The thing is that this is much more difficult than it sounds: - What happens if you do not want to save your image, you forgot to save it or it crashes? Suddenly you will have an image that is not in sync with your repository. Would you load all changes into your image as soon as you reopen it? Atomically? - What happens if you share your repository between several images? - Or if suddenly you change your branch from the command line to something completely different? Several of these usecases don't even make sense. So we preferred to choose the path of "make it explicit". Of course, we could do better, we are open to discuss any improvements. Just take into account that Iceberg did not come from an egg :) we have thought about many possible scenarios and discussed with a lot of people before. !! How does merge work? First, just for the record, merge works. We even - detect fast forward merge avoiding the creation of extra merge commits - proposing a single UI to resolve all conflicts of a project at once and not one per package Now, as Thierry suggested in the other thread, Iceberg's merge happen in memory. The reason behind this is that using Git's default merge mechanism would insert the >>>> <<<< markers in the conflicting files. This would break our parsers and all our tools. Instead, we ask git for the list of conflicting files, and we build a diff tree in memory, that we later augment with information such as conflicts. There are some issues we have seen when merging external files, but as soon as the two merged commits are not merging external files, but we hope we will fix them soon. Missing feature: right now we can only choose between incoming or loaded version during a merge. It would be nice to be able to edit a method's code, picking part of the incoming code and part of the current code. Missing feature 2: right now we resolve all conflicts in memory and commit them at once. We know some people would like to, instead, not do the merge automatically, so they can test it before committing. This should not be tooo difficult to do but it was down in the priority list :). !! Exporting without commiting? There is no UI support for this, but it is doable from the backend, though not correctly exposed right now. You can right-click on the repository -> Extras -> Inspect repository index updateDiskWorkingCopy: repository workingCopy workingCopyDiff. > 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). Well, the UI rewriting has several ideas behind. I'll put whichever ones come to my mind in here, I hope Esteban will correct me if I'm wrong: - Moving from Glamour to Spec. This is a purely technical decision. AFAIK, maybe I'm wrong, Glamour is not being maintained anymore by the GT team, and it has some rough corners that made the old UI difficult to deal with sometimes. From an investment of time standpoint, we decided to put effort in Spec instead... - Simplify the UI. We needed it to be less overwhelming and sometimes more direct. That's the why of the toolbar on the top, and the more (but smaller and simpler) windows. Regarding the design, Esteban followed some UI guidelines for the design taken from I don't where. But at the end we are engineers, not UI designers, so we make ugly UIs by default :P. Any improvement or concrete suggestion on this direction is welcome :). > 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?). > Yes, I want that also. I miss - a Diff/See Changes button. - that the tabs that show the diffs should maybe say "Diff: XXX to YYY" instead of just "XXX to YYY" Could you open an issue? > > 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). > Could you open an issue? > > 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. > Ouki :) Thanks! > > > Tim > > > Sent from my iPhone > -- 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 24, 2018

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

by Serge Stinckwich

On Wed, May 23, 2018 at 3:39 PM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > 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. =) > > âThis quite easy to implement : LibC>>fegetround ^ self ffiCall: #(int fegetround(void))â âLibC>>â fesetround: round ^ self ffiCall: #(void fesetround(int round)) âbut apparently nothing happens when you do : LibC uniqueInstance fesetround: 1024. LibC uniqueInstance fegetround. always return 0.â -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

May 24, 2018

Re: [Pharo-users] On UDP broadcast

by Hilaire

I took a look of course. Thanks. At my basic level of knowledge, I found the articles on the Pharo books and the basic Tests on Socket very helpful. Hilaire Le 23/05/2018 Ã 17:42, N. Bouraqadi a Ã©critÂ : > 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 >> <mailto:cdrick65@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/#%21/%7ECAR/ReusableBricks> >> It has some dependencies on other packages. Â» >> >> It may help. I cc Noury. -- Dr. Geo http://drgeo.eu

May 24, 2018

Re: [Pharo-users] On UDP broadcast

by Hilaire

Hi Henrik, Le 22/05/2018 Ã 10:57, Henrik Sperre Johansen a Ã©critÂ : > With UDP, there is no connection concept, so I'd reckon > waitForConnectionFor: is what gives you a TimeOut error... The #waitForConnectionFor: message seems not to be the issue. I was doing something apparently stupid: I started first the broadcast from the shell, then the listener in Pharo. Funnily I was doing it the other way when using nc to listen. Any way I will still discard #waitForConnectionFor: > 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. ok > 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. If I understand correctly what you suggest, student workstations initiate the broadcast to manifest interest to access My scenario initial idea was a bit more like: 1) server, teacher workstation, continuously broadcast its IP to a specific port. 2) student workstation, when they want to access teacher shares, listen to this port to get the teacher workstation IP 3) once student workstation got the ip, it stops listen for broadcast, and it connects to the to the teacher workstation http server to access the shares. Your scenario does not need a continuously broadcast... > PS. Why use nc when you already have a working broadcast client in pharo?;) Oh, just to play with one variable at a time.Â But seems I introduced a human factor. Thanks Hilaire -- Dr. Geo http://drgeo.eu

May 24, 2018

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

by Sven Van Caekenberghe

Thanks! > On 24 May 2018, at 10:34, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > AAAnd, I've uploaded some of this things to Iceberg's documentation. > > How to contribute to Iceberg: https://github.com/pharo-vcs/iceberg/wiki/Contributing-to-Iceberg > Metacello support: https://github.com/pharo-vcs/iceberg/wiki/Metacello-Support > Branching and merging: https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging > > On Thu, May 24, 2018 at 10:06 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Thu, May 24, 2018 at 9:51 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Tim, > > On Wed, May 23, 2018 at 6:32 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Guille - the text reads very well, Iâll try and look at the videos later. > > Good! > > 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). > > Yes I saw it :) > > (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). > > I'll paste my mail in some readme/iceberg wiki ;) > > > 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 has a very low quality compare to the others. I think maybe a setting was wrong when it was uploaded? > > Ah that's probably my fault. The video editor I'm using has some ugly defaults and I may have forgotten to change the export options for this one? I'll check and replace the video. > > I've uploaded a new version with better quality to > > https://www.youtube.com/watch?v=DBzkjwABPEI > > and marked the old one as deprecated, pointing to the new one (can't replace videos in youtube...). > > > Thanks! > > > 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 >> >> 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. > > > > > -- > > 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 > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13 > > > > -- > > 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 > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13 > > > > -- > > 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 > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

May 24, 2018

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

by Guillermo Polito

AAAnd, I've uploaded some of this things to Iceberg's documentation. How to contribute to Iceberg: https://github.com/pharo-vcs/iceberg/wiki/Contributing-to-Iceberg Metacello support: https://github.com/pharo-vcs/iceberg/wiki/Metacello-Support Branching and merging: https://github.com/pharo-vcs/iceberg/wiki/Branching-and-Merging On Thu, May 24, 2018 at 10:06 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > > > On Thu, May 24, 2018 at 9:51 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi Tim, >> >> On Wed, May 23, 2018 at 6:32 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> >>> Guille - the text reads very well, Iâll try and look at the videos later. >>> >> >> Good! >> >> >>> 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). >>> >> >> Yes I saw it :) >> >>> >>> (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). >>> >> >> I'll paste my mail in some readme/iceberg wiki ;) >> >> >>> >>> 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/watc >>> h?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? >>> >> >> Ah that's probably my fault. The video editor I'm using has some ugly >> defaults and I may have forgotten to change the export options for this >> one? I'll check and replace the video. >> > > I've uploaded a new version with better quality to > > https://www.youtube.com/watch?v=DBzkjwABPEI > > and marked the old one as deprecated, pointing to the new one (can't > replace videos in youtube...). > > >> >> Thanks! >> >> >>> >>> 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 >>> >>> 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. >>> >>> >>> >> >> >> -- >> >> >> >> 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 >> > > > > -- > > > > 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 > -- 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 24, 2018