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

Re: [Pharo-users] ESRI ASCII raster format

by Serge Stinckwich

On Wed, Jun 3, 2020 at 3:27 PM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks for mentioning it. > It can be a super nice exercise. > with a line based constructor. > It can be super fun to code for a book chapter. > Yes I think so. This is not super complicated from what I see in the format description. For when do you need it? > > ASAP, but we can wait :-) This is part of our work on the migration of CORMAS from VW to Pharo: https://github.com/cormas/cormas At the moment, the code to support this format is entangled in the grid model ... We can even do a pair programming session with you and other CORMERS. We are doing weekly meeting on Discord. Thank you. Regards, -- Serge Stinckwic h https://twitter.com/SergeStinckwich

June 3, 2020

Re: [Pharo-users] ESRI ASCII raster format

by StÃ©phane Ducasse

Thanks for mentioning it. It can be a super nice exercise. with a line based constructor. It can be super fun to code for a book chapter. For when do you need it? S. > On 3 Jun 2020, at 04:01, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > Dear all, > > I'm looking for an implementation of ESRI ASCII raster format: > http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/ESRI_ASCII_ra… <http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/ESRI_ASCII_ra…> > > We are looking for such an implementation for CORMAS: > https://github.com/cormas/cormas/issues/135 <https://github.com/cormas/cormas/issues/135> > > Thank you. > Regards, > -- > Serge Stinckwich > https://twitter.com/SergeStinckwich <https://twitter.com/SergeStinckwich> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

June 3, 2020

ESRI ASCII raster format

by Serge Stinckwich

Dear all, I'm looking for an implementation of ESRI ASCII raster format: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/ESRI_ASCII_ra… We are looking for such an implementation for CORMAS: https://github.com/cormas/cormas/issues/135 Thank you. Regards, -- Serge Stinckwic h https://twitter.com/SergeStinckwich

June 3, 2020

Problems installing pharo-launcher or pharo on RaspberryPi

by Michael Burns

Raspberry Pi 4. I went to pharo.org/download And downloaded both PharoLauncher-linux-2.0-x64.zip and pharo-linux-stable.zip. I extracted them into separate directories. I believe Pi 4 B is indeed 64 bit, but read somewhere that the Raspian installer installs a 32 bit O/S. I would expect uname to tell me which. It just says Linux pi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux Both of these these files extracted say the same thing when I try to run them: 64 bit: pi@pi:~/Pharo/pharolauncher $ ./pharo-l* Error. Could not determine platform's libc path for VM. Try forcing $PLATFORMLIBDIR in /home/pi/Pharo/pharolauncher/pharo-vm/pharo, based on LIBC_SO. Please report what works to pharo [vm-dev] mail list. LIBC_SO= PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian UNAME=Linux pi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux 32 bit: pi@pi:~/Pharo/32 bit/pharo-linux-stable/bin $ ./pharo Error. Could not determine platform's libc path for VM. Try forcing $PLATFORMLIBDIR in ./pharo, based on LIBC_SO. Please report what works to pharo [vm-dev] mail list. LIBC_SO= PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian UNAME=Linux pi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux Any clues?

June 2, 2020

Re: [Pharo-users] About strange email related to smalltalkhub read-only on squeak-dev

by StÃ©phane Ducasse

What I do not like is that people say " group but they keep kicking me out of their mailing list â when this is absolutely not true! We can discuss and can argue even violently but we do not lie. S. > On 31 May 2020, at 19:38, Bruce O'Neel <bruce.oneel(a)pckswarms.ch> wrote: > > > Hi, > > So addressing only the crypto software issue and with the caveat that I am also not a lawyer but I have had to deal with certain aspects of this in the past.... > > Crypto software is one of those bizarre dual use items in terms of arms imports and exports. While we as geeks just think of this is software or mathematics and might be confused as to why governments care, governments do care deeply about this. And their way of expressing how much they care about this issue is by passing laws and prosecuting folks. > > One of the easiest ways to get in trouble is for one to make the software available to residents and/or citizens of certain countries as well as available to people on a long list kept by different governments. We can have a long debate about the morality of this concept but those who make the laws have decided that is the law. And often these laws are crafted such that the executive can change important details on short notice and that puts the risk of prosecution at the whims of different world leaders. > > The license that the software is released under is not important. > > What Ron is stating is that squeak source supplied some additional protections to prevent accidentally making the software available to folks who the US feels should not have access. > > If you have moved the software to another hosting provider without the permission or knowledge of the author, and therefore the owner of the software, you have put that person at additional risk. In addition you and the hosting provider are taking on additional risk. > > If it was moved to GitHub I strongly recommend reviewing their policies on trade controls and what risks you assume. > > https://help.github.com/en/github/site-policy/github-and-trade-controls <https://help.github.com/en/github/site-policy/github-and-trade-controls> > > Finally I would strongly recommend talking to a competent legal advisor who is deeply familiar with the details of these laws. They are complex and highly variable between different parts of the world. > > I know this seems like a lot of trouble and wasted time but you can spend a giant amount of time and money defending oneself from arms trafficking charges. > > cheers > > bruce > > 30 May 2020 14:43 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi all > > This is the week-end and we worked super well yesterday during the sprint. Lot of good enhancements - Thanks a lot to all the participants. > I not really happy to be forced to do it on a sunny saturday but Iâm doing it to clarify points. > > Esteban sent me this text that was posted on Squeak-Dev (I personally do not read squeak related forums because > I have not the time and my focus is Pharo, its consortium, my team, my research and my family). > > We have to react because > - We do not really at ***all** understand this email > - We did not kicked anybody from our mailing-list from ages - so ron is lying. In the past we even had discussion with ron - so we do not > really understand. May be we got problem to log on our mailing-lists. > We have no idea because we are working and not looking at such things. > - When we migrated smalltalkhub to readonly we payed attention to make sure that private projects stay private. > We did not migrated smalltalkhub for fun. We MUST do it or it will be done by our infrastructure! > - Now the cryptography packages are MIT and they are public anyway. So again we do not understand anything. > > We do not get why Ron contacted us because we announced the migration publicly way in advance and we will keep > the Smalltalkhub frozen repo for at least next 5 years. > > I feel really sorry to hear such kind of email because we do not want to fight with anybody. > Our goal is to make sure that people can work with Pharo and expand their business and knowledge. > We are working hard to make sure that people can invent their future with Pharo and people that know us personally > know that we are not lying. > > S > > > >> Hi all, >> >> I've tried to work with the Pharo group but they keep kicking me out of their mailing list. I've already mentioned this a number of times to the Pharo group but nobody seems to care. >> >> BOLD BOLD BOLD PLEASE TAKE THIS SERIOUSLY BOLD BOLD BOLD >> >> I am not a lawyer but we used very good lawyers to make the squeaksource repository a safe place to do cryptography work. If you are working on cryptography DO NOT POST your code anywhere except squeaksource. Especially if you are in the USA. The ONLY repository that is approved to host our cryptography code in the USA and therefore not subject to criminal violations is squeaksource. It is a CRIME in the USA to move code and make it available on the internet for everyone to download! It must be hosted on squeaksoruce.com <http://squeaksoruce.com/> or another location that is also properly registered. >> >> IF YOU COPIED CRYPTOGRAPHY CODE TO ANOTHER REPOSITORY THAT IS NOT REGISTERED I would recommend you delete it immediately. >> >> END BOLD! >> >> Please feel free to post this to the Pharo mailing list because they apparently do not want to hear from me! >> >> All the best, >> >> Ron Teitelbaum > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <http://www.pharo.org/> > 03 59 35 87 52 > Assistant: Aurore Dalle > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

June 2, 2020

Re: [Pharo-users] Few newbie questoins about Pharo/Smalltalk capabilities

by StÃ©phane Ducasse

> On 2 Jun 2020, at 13:00, gustav_m <gustavmoist(a)gmail.com> wrote: > > Hello! I don't know if this is a good place to ask this kind of questions, > but I haven't found other places where Smalltalk/Pharo experts hang out. You can join the discord channel and talk with people. https://discord.gg/QewZMZa <https://discord.gg/QewZMZa> > > I'm a designer and unfortunately I know nothing about programming and > computation. I'm trying to change this right now. I'm looking for suitable > technology to learn and so far Pharo/Smalltalk looks very promising. To be > honest, it looks way too good to be true. And that's why I'm here, asking > you guys to disillusion me. What is really interesting with Pharo is that you have less qwirk than in other languages to learn. It is uniform so once you get it you get all the stack. Now this uniformity can be also difficult to grasp. But there are some aspects you can ignore when you start. What I really love is that you can touch everything (nearly) you can go super super deep and change the compiler or the graphics. And this different parts are still following the same small model and use the same tiny syntax. > I work in a small department of a large company (unfortunately I can't give > you too much details). Part of my job is to design tools that are used by > our team. Every time I come up with an idea, we need to get a programmer > from other department and we work together to bring my idea to life. So it > would be perfect if I could do the programming on my own. > We are lucky that we are not tied to any particular technology (at least in > our department, for now). Some of our tools were written in Java, some in > Python. Sometimes what is frustrating for me is that the widgets are not good enough. But for example a group a thales is designing super specific UI for the army and they do all the requirement engineering and design super ad-hoc User interfaces. What they particularly love (I can put you in contact with them) is that they can fully change Pharo. You would not recognise it when you see their system. They built a platform for building specific UI and now they are rebuilding it in Pharo. Iâm about to send a new success story with a visual They cannot show the software that they build for the army but did âstrangeâ UI for the submarine or also tatical system. Here is a sample of the public image that they can send. You can also look at Feenk.com because all their stack is based on an alternate graphical layer that they developed. It is gorgeous. > > After watching this video [https://youtu.be/AnrlSqtpOkw?t=550] my > imagination just went crazy. It looks like the Smalltalk system would be > also a perfect tool to give presentations to my superiors. > So to me Smalltalk looks like a holy grail. But again, my perception of it > is probably wrong and I might be better of learning, for instance, > Dart+Flutter. Well the problem is really that you should go slowly and learn step by step. Because programming is a skill that should be practiced. Now what is important to consider is that Pharo is not a black box. Once you understand the principle you can morph the complete environment. And when you program it you do not program a mere file, you are editing a life environment (which can blow on your face if you kill it) but this is super powerful. > So here is a bunch of questions, I hope someone will find time to answer > (and I do apologize in advance, as I'm sure you may find this questions > infantile and annoying): > 1. As a designer I'm an aesthete. Is it possible to change the look of the > windows and the environment to ones liking? Yes The super basic is the change the color (I was fed up by the greish and in our team people hacking different coloring scheme) but you can also change the rest. People in the past did skins and the windows were really different. > Or redesign the whole system to > not use windows at all? Yes > How moldable the environment is? I would say that the limits are your skills. For exampel once we wanted to see if we can introduce our own gesture recognition and we ask a third year student (a good one) to do it. We will now be able to use what he did (you can find this on youtube https://www.youtube.com/watch?v=t_6xbAVIlH0 have a look at what tomohiro did for fun https://www.youtube.com/watch?v=eYuhlixBaPI <https://www.youtube.com/watch?v=eYuhlixBaPI> look for pharo honeyginger youtube tomohiro https://www.youtube.com/watch?v=Wq6APgF1ZHc > 2. How well is Smalltalk/Pharo suited to handle different graphic animation > effects? As a designer I like to use animations to cue users. What about > sound effects? Have a look the roassal 30 twitter account it is full of animation. https://twitter.com/brackendev/status/1206776380844838914/photo/1 <https://twitter.com/brackendev/status/1206776380844838914/photo/1> Milton is posting them regularly and really nice person https://twitter.com/akevalion > Also, as a hobby I'd like to try some (3.) generative art Look at roassal 30 :) > and (4.) agent > based modeling. Is Pharo suitable for this kind of things? Yes https://github.com/tomooda/ReMobidyc <https://github.com/tomooda/ReMobidyc> > From what I saw and read it may be good choice for ABM, but some people cry > about Smalltalk being slow. Slow compare to what? Pharo is faster than may be modern language. > So maybe I'd be wiser to learn Processing (for > 3) and NetLogo (for 4) instead. This would be unfortunate as these are two > another technologies to learn. You should try and be in contact with people and measure. > 5. And the last question- as I skimmed through "Blue Book" I found so called > "Pen" class. However, it looks like it's missing in Pharo. Was it removed? > And if so, why? The blue book is nearly thirty year old and we removed it. because it was writing in plain memory and not of real use. To teach programming I wrote a turtle like system https://botsinclearners.github.io <https://botsinclearners.github.io/> And I should finish to migrate the siteâ¦ but you can check the videos and the graphic art that an old art retired teacher did with it. https://github.com/BotsIncLearners/botsincLearners.github.io/blob/source/im… https://github.com/BotsIncLearners/botsincLearners.github.io/tree/source/im… > I find the language itself, and especialy its minimalism/simplicity, so > elegant, that I'm thinking of printing the famous "postcard example" and > hanging it on a wall. The whole system, however, is humongous! It looks like > learning (to be albe to do anything interesting and non-trivial) will take > ages. The point is that you do not have to learn everything. You have to know the basic and learn how to find your way. There is a mooc we are about to release new videos for the version 80 but you can take the current version of the mooc on (I think that luc changed mooc.pharo.org <http://mooc.pharo.org/> to use the version 80 - you have dub version and version with subtitles) https://www.fun-mooc.fr <https://www.fun-mooc.fr/> What I can tell you is that we are not teaching Pharo and it takes in general 2 weeks to a third year students to get up to speed. You also have the book "Learning Oop â and "Pharo by exampleâ to start with. Iâm porting the book to Pharo80 But what I can tell is that you do not have to understand everything. Luckily. > So, what do you think? Should I invest my time here? Or is there a different > technology that I should consider? My gut feeling is that playing with Pharo will fundamentally change your perception. I often say to people that visit us that even if after they will never program anymore in Pharo, they usually will not program the same after. So my suggestions - check the mooc - be connected on discord and ask questions - we can also help with some share screen session if necessary (I do that from time to time with students). - and evaluate what you will learn - pick small challenges - check roassal30 Pharo is a mid term play. in the sense that it requires some investisemnt > > Gustav > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

June 2, 2020

Re: [Pharo-users] Zinc WebSocket usage

by Sven Van Caekenberghe

Erik, Yes, I saw your previous email, answering it was on my todo list ;-) I took Pharo 9 on macOS 10.15 and did: Metacello new repository: 'github://svenvc/zinc/repository'; baseline: 'ZincHTTPComponents'; load: #(WebSocket). (Accepting loads over existing code) Although your example is clear, and I could run it, it is still a bit unclear to me what you actually want to do architecturally. Indeed, it takes 30s (the timeout) for the reading on the client side (inside the #runWith:) to react to the closing in the case of ZnWebSocket>>#close (which sends #close to the stream/socket). Your alternative works, because in that case, the other end (server side) closes, which apparently triggers the reading on the client side out of its timeout. Why this does not work is not clear to me (note the 2 process interact with the socket). There are several ways to change the timeout, the simplest is globally doing: ZnNetworkingUtils defaultSocketStreamTimeout: 5. But it would be better to do it dynamically (that is possible but another story). Anyway changing the timeout to 5s and logging the time using: | server client | server := ZnWebSocket startServerOn: 1701 do: [ :webSocket | [ webSocket runWith: [ :message | Transcript show: 'Received message: ', message printString ; cr ] ] on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ]. Transcript show: 'The server is closed @' , DateAndTime now asString; cr ]. client := ZnWebSocket to: (ZnUrl fromString: 'ws://localhost:1701'). [ [ client runWith: [ :message | "ignore received messages" ] ] on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ]. Transcript show: 'The client is closed@' , DateAndTime now asString; cr. server stop ] fork. (Delay forSeconds: 1) wait. client sendMessage: 'Hello world'. client close. "Workaround: use the following instead of 'client close'." "client sendFrame: ZnWebSocketFrame close." { server. client }. Shows indeed the difference between 30s and 5s. Now, if you only want to send a message, why not do: | server client | ZnNetworkingUtils defaultSocketStreamTimeout: 5. server := ZnWebSocket startServerOn: 1701 do: [ :webSocket | [ webSocket runWith: [ :message | Transcript show: 'Received message: ', message printString ; cr ] ] on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ]. Transcript show: 'Server websocket closed @' , DateAndTime now asString; cr ]. client := ZnWebSocket to: 'ws://localhost:1701'. client sendMessage: 'Hello world'. client close. { server. client }. This works fine/immediately (since there is no pending read to interact with). That is why I was asking what your architecture is. Because if you want to do asynchronous reading and writing, from different processes, things will inevitably get more complicated. BTW: the server does not close, just the server side web socket. Sven > On 2 Jun 2020, at 19:06, Erik Stel <erik.stel(a)gmail.com> wrote: > > Hi Sven, > > Maybe you missed the additional post with the source code (I attached it > again below with small change in way it is logging). Is there any advice on > how to do this (other than the workaround I'm using at the moment)? The > issue being that the client recognises its own closing only after a timeout > (around 30 seconds by default). A message "Client closed" will appear on the > Transcript after this 30 seconds. With the workaround (see comment in code), > it does recognise the closing immediately. > > As you can see, I'm already using #runWith: as you suggested. Your recent > addition of sending 'ping' does not change the synchronous behaviour. > > I'm using this on a Pharo 7 image, but also tested it on Pharo 9. > > Kind regards, > Erik > > Just in case, I added the code again (without using #crLog: this time): > > | server client | > server := ZnWebSocket startServerOn: 1701 do: [ :webSocket | > [ webSocket runWith: [ :message | Transcript show: 'Received > message: ', message > printString ; cr ] ] > on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ]. > Transcript show: 'The server is closed' ; cr ]. > client := ZnWebSocket to: (ZnUrl fromString: 'ws://localhost:1701'). > [ > [ client runWith: [ :message | "ignore received messages" ] ] > on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ]. > Transcript show: 'The client is closed' ; cr. > server stop ] fork. > (Delay forSeconds: 1) wait. > client sendMessage: 'Hello world'. > client close. > "Workaround: use the following instead of 'client close'. > client sendFrame: ZnWebSocketFrame close." > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

June 2, 2020

Re: [Pharo-users] Rename package and Iceberg

by Vitor Medina Cruz

Ok, thanks! On Tue, Jun 2, 2020 at 12:31 PM Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Iceberg is showing what will happen with the files on the repository. Git > is pretty good inferring that it was a rename (because the folders changed > too), unless you also change the code in the same commit that you made the > rename. I don't think its a bug but I will create a new improvement issue > for Iceberg: to improve on one side the package rename case (because having > to do it manually is painful), and on the other hand the diff can be more > intelligent in those cases. > > Regards, > Gabriel > > On Tue, Jun 2, 2020 at 10:08 AM Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> Humm, you are right, in git it is correct, but strangely iceberg seems to >> think otherwise: >> >> [image: image.png] >> >> >> [image: image.png] >> >> [image: image.png] >> >> I will do that so, but this behavior in Iceberg seems an errorto me, or >> don't? Should I open an issue for this? >> >> Regards, >> Vitor. >> >> >> On Tue, Jun 2, 2020 at 9:53 AM Gabriel Cotelli <g.cotelli(a)gmail.com> >> wrote: >> >>> If you add the new packages and remove the old ones the history will be >>> ok. For example: https://github.com/ba-st/Willow/pull/160/files , and >>> don't forget to update your baseline. >>> >>> On Tue, Jun 2, 2020 at 9:48 AM Vitor Medina Cruz <vitormcruz(a)gmail.com> >>> wrote: >>> >>>> So you mean I should change the package name and add the renamed >>>> package as a new one into Inceberg? The problem with this is that the >>>> history will be compromised, as it will see it as exclusion and then >>>> inclusion of several new classes instead of simply changes in existing >>>> ones. >>>> >>>> Isn't a way o doing that keeping the correct history of changes? >>>> >>>> On Tue, Jun 2, 2020 at 9:33 AM Gabriel Cotelli <g.cotelli(a)gmail.com> >>>> wrote: >>>> >>>>> You need to open the repository view, add your new packages using the >>>>> Add Package button and remove the old ones with the contextual menu. >>>>> >>>>> On Tue, Jun 2, 2020 at 9:27 AM Vitor Medina Cruz <vitormcruz(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> How is the correct/safe way of renaming a packages so that it is >>>>>> reflected in the Iceberg repository? >>>>>> >>>>>> I have made that sometimes but got out of sync with Iceberg and it >>>>>> was very hard to fix: I had to change files by hand, and then load back in >>>>>> the image, so wanna to avoid that. >>>>>> >>>>>> Regards, >>>>>> Vitor. >>>>>> >>>>>

June 2, 2020

Re: [Pharo-users] Zinc WebSocket usage

by Erik Stel

Hi Sven, Maybe you missed the additional post with the source code (I attached it again below with small change in way it is logging). Is there any advice on how to do this (other than the workaround I'm using at the moment)? The issue being that the client recognises its own closing only after a timeout (around 30 seconds by default). A message "Client closed" will appear on the Transcript after this 30 seconds. With the workaround (see comment in code), it does recognise the closing immediately. As you can see, I'm already using #runWith: as you suggested. Your recent addition of sending 'ping' does not change the synchronous behaviour. I'm using this on a Pharo 7 image, but also tested it on Pharo 9. Kind regards, Erik Just in case, I added the code again (without using #crLog: this time): | server client | server := ZnWebSocket startServerOn: 1701 do: [ :webSocket | [ webSocket runWith: [ :message | Transcript show: 'Received message: ', message printString ; cr ] ] on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ]. Transcript show: 'The server is closed' ; cr ]. client := ZnWebSocket to: (ZnUrl fromString: 'ws://localhost:1701'). [ [ client runWith: [ :message | "ignore received messages" ] ] on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ]. Transcript show: 'The client is closed' ; cr. server stop ] fork. (Delay forSeconds: 1) wait. client sendMessage: 'Hello world'. client close. "Workaround: use the following instead of 'client close'. client sendFrame: ZnWebSocketFrame close." -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 2, 2020

Re: [Pharo-users] Rename package and Iceberg

by Gabriel Cotelli

Iceberg is showing what will happen with the files on the repository. Git is pretty good inferring that it was a rename (because the folders changed too), unless you also change the code in the same commit that you made the rename. I don't think its a bug but I will create a new improvement issue for Iceberg: to improve on one side the package rename case (because having to do it manually is painful), and on the other hand the diff can be more intelligent in those cases. Regards, Gabriel On Tue, Jun 2, 2020 at 10:08 AM Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Humm, you are right, in git it is correct, but strangely iceberg seems to > think otherwise: > > [image: image.png] > > > [image: image.png] > > [image: image.png] > > I will do that so, but this behavior in Iceberg seems an errorto me, or > don't? Should I open an issue for this? > > Regards, > Vitor. > > > On Tue, Jun 2, 2020 at 9:53 AM Gabriel Cotelli <g.cotelli(a)gmail.com> > wrote: > >> If you add the new packages and remove the old ones the history will be >> ok. For example: https://github.com/ba-st/Willow/pull/160/files , and >> don't forget to update your baseline. >> >> On Tue, Jun 2, 2020 at 9:48 AM Vitor Medina Cruz <vitormcruz(a)gmail.com> >> wrote: >> >>> So you mean I should change the package name and add the renamed package >>> as a new one into Inceberg? The problem with this is that the history will >>> be compromised, as it will see it as exclusion and then inclusion of >>> several new classes instead of simply changes in existing ones. >>> >>> Isn't a way o doing that keeping the correct history of changes? >>> >>> On Tue, Jun 2, 2020 at 9:33 AM Gabriel Cotelli <g.cotelli(a)gmail.com> >>> wrote: >>> >>>> You need to open the repository view, add your new packages using the >>>> Add Package button and remove the old ones with the contextual menu. >>>> >>>> On Tue, Jun 2, 2020 at 9:27 AM Vitor Medina Cruz <vitormcruz(a)gmail.com> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> How is the correct/safe way of renaming a packages so that it is >>>>> reflected in the Iceberg repository? >>>>> >>>>> I have made that sometimes but got out of sync with Iceberg and it was >>>>> very hard to fix: I had to change files by hand, and then load back in the >>>>> image, so wanna to avoid that. >>>>> >>>>> Regards, >>>>> Vitor. >>>>> >>>>

June 2, 2020