- Pharo-users - lists.pharo.org

Re: [Pharo-users] Spec Question

by Benjamin

Text is accepted when you âsaveâ it (cmd+s) Ben On 24 Oct 2013, at 14:05, Manfred KrÃ¶hnert <mkroehnert42(a)googlemail.com> wrote: > Hi everyone, > > I finally got around to check back on a Spec question that popped up about two weeks ago. > > At that time I was giving Spec a first try and gathered information from a couple of sources. > One of them was the draft chapter about Spec from the Pharo for the Enterprise book. > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/ws/Spec/Sp… > > The example has the following method: > > TestSpec>>initializePresenter > example whenTextIsAccepted: [ changes text: 'The text Changed'. acceptChanges enable ]. > > This should change the text of the 'changes' LabelModel when the text in the 'example' TextModel is accepted. > > Now, there the issue for me was that the Label text did not change once when I typed text into the presented textfield. > Even when I changed the method from 'whenTextIsAccepted:' to 'whenTextChanged:'. > Is this intended or is this an issue with Spec? > > Also, it is not clear to me what 'accepting' text means (maybe I didn't look thoroughly enough). > The method comment just states that it is called when the text is accepted. > Which is kind of self referential ;-) > > The OS X Pharo versions I used for testing where newly downloaded Pharo 2.0 and 3.0 from about 2 weeks ago. > They were downloaded from here: > http://files.pharo.org/platform/Pharo2.0-mac.zip > http://files.pharo.org/platform/Pharo3.0-mac.zip > > Best, > Manfred

Oct. 24, 2013

Spec Question

by Manfred KrÃ¶hnert

Hi everyone, I finally got around to check back on a Spec question that popped up about two weeks ago. At that time I was giving Spec a first try and gathered information from a couple of sources. One of them was the draft chapter about Spec from the Pharo for the Enterprise book. https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/ws/Spec/Sp… The example has the following method: TestSpec>>initializePresenter example whenTextIsAccepted: [ changes text: 'The text Changed'. acceptChanges enable ]. This should change the text of the 'changes' LabelModel when the text in the 'example' TextModel is accepted. Now, there the issue for me was that the Label text did not change once when I typed text into the presented textfield. Even when I changed the method from 'whenTextIsAccepted:' to 'whenTextChanged:'. Is this intended or is this an issue with Spec? Also, it is not clear to me what 'accepting' text means (maybe I didn't look thoroughly enough). The method comment just states that it is called when the text is accepted. Which is kind of self referential ;-) The OS X Pharo versions I used for testing where newly downloaded Pharo 2.0 and 3.0 from about 2 weeks ago. They were downloaded from here: http://files.pharo.org/platform/Pharo2.0-mac.zip http://files.pharo.org/platform/Pharo3.0-mac.zip Best, Manfred

Oct. 24, 2013

Re: [Pharo-users] Tip: Recovering a broken image

by Sven Van Caekenberghe

Hi Bernat, Interesting, I never heard of #backupTo: But if recover.image is a copy of MyImage.image, and that last one failed to start up, why then would the copy not have the same problem ? Sven On 24 Oct 2013, at 13:32, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Hi list, > > I've just recovered a broken image that crashed upon startup. There was some problem with a SerialPort that stayed open and tried to write/read into a physical port that didn't exist no more, or something of the sort. > > So here's the magic line: > > $ bin/myVm shared/MyImage.image eval "SmalltalkImage backupTo: 'recover'" > > This makes a copy of the image into a new image called "recover.image", but as the documentation states: > > Unlike #saveAs: do not transfer the default execution to the new image. > > So there you go! > > Hope it helps someone else. :) > > -- > Bernat Romagosa.

Oct. 24, 2013

Tip: Recovering a broken image

by Bernat Romagosa

Hi list, I've just recovered a broken image that crashed upon startup. There was some problem with a SerialPort that stayed open and tried to write/read into a physical port that didn't exist no more, or something of the sort. So here's the magic line: $ bin/myVm shared/MyImage.image eval "SmalltalkImage backupTo: 'recover'" This makes a copy of the image into a new image called "recover.image", but as the documentation states: *Unlike #saveAs: do not transfer the default execution to the new image. * So there you go! Hope it helps someone else. :) -- Bernat Romagosa.

Oct. 24, 2013

Re: [Pharo-users] Zinc: How to use the @ character in an URL

by Sven Van Caekenberghe

Good, thanks a lot for the feedback ! Sven On 24 Oct 2013, at 12:05, Olivier Auverlot <olivier.auverlot(a)gmail.com> wrote: > Hi Sven, > > Fantastic work ! I just tested the new version and it seem that all is ok. > > Olivier ;-) > >

Oct. 24, 2013

Re: [Pharo-users] Zinc: How to use the @ character in an URL

by Olivier Auverlot

Hi Sven, Fantastic work ! I just tested the new version and it seem that all is ok. Olivier ;-)

Oct. 24, 2013

Re: [Pharo-users] Zinc: How to use the @ character in an URL

by Sven Van Caekenberghe

Hi Olivier, Can you please test the latest Zn with your use case ? You can load ConfigurationOfZincHTTPComponents from StHub and do ConfigurationOfZincHTTPComponents project bleedingEdge load. The are the relevant commits: === Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.22 Author: SvenVanCaekenberghe Time: 24 October 2013, 10:40:00.795063 am UUID: 3d7bc73c-48b3-40af-8c01-5ba533472a92 Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.21 Made the default safeSet of ZnPercentEncoder an explicit constant named #rfc3986UnreservedCharacters === Name: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.21 Author: SvenVanCaekenberghe Time: 24 October 2013, 10:48:32.342296 am UUID: 7401fc4c-0f26-46e4-8f7d-b0bf10e8352c Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.20 Rewrote ZnUrl percent encoding to use safe sets per component; Fixed a bug in ZnUrl>>#parseAuthority:from:to: where end was not respected (Thx Olivier Auverlot); Removed/renamed ZnResourceMetaUtils class>>#encodePercent:withEncoding to #encodePercent:[safeSet:]encoding: Added some safeSet constants to ZnResourceMetaUtils === Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.13 Author: SvenVanCaekenberghe Time: 24 October 2013, 10:50:11.698368 am UUID: 2d73205c-3415-4597-8d98-abcff1e16259 Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.12 Added ZnUrlTests>>#testComponentSpecificEncoding Fixed ZnUrlTests>>#testQueryEncoding Fixed ZnMimeTypeTests>>#testLegacy === It should work, let me know how it goes ;-) Sven On 24 Oct 2013, at 08:01, Olivier Auverlot <olivier.auverlot(a)gmail.com> wrote: > Thanks for the improvement. Don't hesitate to contact me if I can help you > > Olivier ;-) > > Le 22 oct. 2013 Ã 18:49, Sven Van Caekenberghe a Ã©crit : > >> >> On 22 Oct 2013, at 18:27, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> Ok, point taken. >>> >>> Still, ZnClient is unusable for the intended purpose as is. No matter what encoding, % or not, Olivier cannot get the URL to work. Couldn't the ZnClient use something like the StampClient does: options? (where prefetch-count can be set for example - I also discovered the little inbox thing after some hair pulling sessions BTW). >>> >>> >>> Phil >> >> But Olivier's problem is that he is talking to a server that does not do proper percent decoding, IMHO. A server parsing a URL should resolve all percent encodings, after parsing using the significant delimiters (/ : ? #). >> >> http://foo.com/abc and http://foo.com/%61%62%63 are the same thing, just like http://foo.com/abc@1 and http://foo.com/abc%401 are - again as far as I understand it. >> >> That being said, I am going to study the specs again and might change what gets encoded or not depending on the URL element, instead of encoding aggressively in the better safe than sorry way. >> >> Olivier's suggestion about safer authorisation parsing does make sense and will get added as well - Thanks Olivier ! >> >> Sven >> >> PS: BTW, ZnClient has such an option object already. >> >> > >

Oct. 24, 2013

Re: [Pharo-users] Zinc: How to use the @ character in an URL

by Olivier Auverlot

Thanks for the improvement. Don't hesitate to contact me if I can help you Olivier ;-) Le 22 oct. 2013 Ã 18:49, Sven Van Caekenberghe a Ã©crit : > > On 22 Oct 2013, at 18:27, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> Ok, point taken. >> >> Still, ZnClient is unusable for the intended purpose as is. No matter what encoding, % or not, Olivier cannot get the URL to work. Couldn't the ZnClient use something like the StampClient does: options? (where prefetch-count can be set for example - I also discovered the little inbox thing after some hair pulling sessions BTW). >> >> >> Phil > > But Olivier's problem is that he is talking to a server that does not do proper percent decoding, IMHO. A server parsing a URL should resolve all percent encodings, after parsing using the significant delimiters (/ : ? #). > > http://foo.com/abc and http://foo.com/%61%62%63 are the same thing, just like http://foo.com/abc@1 and http://foo.com/abc%401 are - again as far as I understand it. > > That being said, I am going to study the specs again and might change what gets encoded or not depending on the URL element, instead of encoding aggressively in the better safe than sorry way. > > Olivier's suggestion about safer authorisation parsing does make sense and will get added as well - Thanks Olivier ! > > Sven > > PS: BTW, ZnClient has such an option object already. > >

Oct. 24, 2013

Re: [Pharo-users] Three copies of JSON-ul.35 on Smalltalkhub

by Paul DeBruicker

Hi Stef, Sure add me to that one . I'll delete mine and we'll go from there. Paul On Oct 23, 2013, at 2:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 23, 2013, at 10:25 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > >> There are (at least) three locations of the JSON-ul.35 package on Smalltalkhub. >> >> Here: >> http://smalltalkhub.com/#!/~NicolasPetton/JSON/ >> >> here: >> http://smalltalkhub.com/#!/~PharoExtras/JSON/ >> >> and here: >> http://smalltalkhub.com/#!/~pdebruic/JSONg >> >> >> >> I've also unknowingly duplicated Stef's efforts at making a ConfigurationOfJSON again here: >> >> http://smalltalkhub.com/#!/~pdebruic/JSONg (but this version includes the JSON port to Gemstone) >> >> >> Which of the above should we treat as the canonical JSON repository? > > If you want to have access to the PharoExtras just ask. > I like the idea that a team can maintain a set of used libraries. >> >> >> Thanks >> >> >> Paul > >

Oct. 23, 2013

Re: [Pharo-users] Three copies of JSON-ul.35 on Smalltalkhub

by StÃ©phane Ducasse

On Oct 23, 2013, at 10:25 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > There are (at least) three locations of the JSON-ul.35 package on Smalltalkhub. > > Here: > http://smalltalkhub.com/#!/~NicolasPetton/JSON/ > > here: > http://smalltalkhub.com/#!/~PharoExtras/JSON/ > > and here: > http://smalltalkhub.com/#!/~pdebruic/JSONg > > > > I've also unknowingly duplicated Stef's efforts at making a ConfigurationOfJSON again here: > > http://smalltalkhub.com/#!/~pdebruic/JSONg (but this version includes the JSON port to Gemstone) > > > Which of the above should we treat as the canonical JSON repository? If you want to have access to the PharoExtras just ask. I like the idea that a team can maintain a set of used libraries. > > > Thanks > > > Paul

Oct. 23, 2013